Re: Intent To Split: netbase
Manoj Srivastava [EMAIL PROTECTED] writes: John Anyway, I think the current situation is largely fine, although John I am still dismayed by the lack of statically-linked binaries John in /sbin. If I recall corectly, the argument went that we had a rescue disk, so we did not needto bloat / with bigger binaries. I note this argument has weaknesses, in that one may not always have a rescue disk handly, or one may need static binaries for remote work; however, with sash statically linked, I am more or less satisfied with the state of things. sash covers most of it, with the notable and important exception of fsck, fdisk, and, on i386 platforms, lilo. -- John Goerzen [EMAIL PROTECTED] www.complete.org Sr. Software Developer, Progeny Linux Systems, Inc.www.progenylinux.com #include std_disclaimer.h [EMAIL PROTECTED]
Re: Intent To Split: netbase
John == John Goerzen [EMAIL PROTECTED] writes: John Actually, this is incorrect. On platforms predating John FHS/FSSTND, /sbin was for statically-linked binaries -- John versions of vital system tools (fsck, sh, etc) linked John statically for repair in an emergency. You may recall I have John advocated having a few statically-linked binaries in Debian John packages in the past. Hmm. Well, I was there, before the FHS dasys. Indeed, from a FAQ dating circa 1987 from good old Ultrix days (well, give or take a couple of years), DEC called sbin for +system_ binaries -- programs that could be required by an administrator to recover the system. ``A number of them are also statically linked to aid in this process'', it goes on to say. Indeed, there were two versions of ls -- a static, minimal one in /sbin, and the full featured one in /usr/bin. John Anyway, I think the current situation is largely fine, although John I am still dismayed by the lack of statically-linked binaries John in /sbin. If I recall corectly, the argument went that we had a rescue disk, so we did not needto bloat / with bigger binaries. I note this argument has weaknesses, in that one may not always have a rescue disk handly, or one may need static binaries for remote work; however, with sash statically linked, I am more or less satisfied with the state of things. manoj -- And it's so portable --- at least, it worked on every VAX that I tried it on. Tim McDaniel ([EMAIL PROTECTED]) 6 Sep 90, [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
I'll be happy to do whatever is required for sendmail, but we also need the assistance of (at least - any others?): LaMont Jones [EMAIL PROTECTED] postfix If someone wants to tell me exactly what to change and how (I haven't had to deal with alternatives before...), I'd be happy to make the change and submit. Do we need/want to do all of these at once, or can they happen separately? lamont
Re: mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 01:06:26PM -0700, tony mancill wrote: I disagree. You *NEED* to have a copy of mke2fs in the root filesystem in case /usr or any other mounted filesystem gets whacked. OTOH, you probably won't be mastering any CD images while your system is crippled, so having mkisofs in /usr is not inconsistent. Er, uh, /bin and /sbin are BOTH usually on the root filesystem. I think this point is orthogonal to the sbin vs. bin argument. -- G. Branden Robinson | What influenced me to atheism was Debian GNU/Linux| reading the Bible cover to cover. [EMAIL PROTECTED] | Twice. http://www.debian.org/~branden/ | -- J. Michael Straczynski pgpPYe9Sx5a01.pgp Description: PGP signature
Re: Intent To Split: netbase
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden Could you remind me what these benefits are again? Pretend Branden for a moment that the FHS doesn't exist and it's entirely up Branden to us. What exactly DO we gain by having some binaries Branden segregated off into sbin? You and I? Perhaps nothing. But then, we are not exactly typical users either. A novice? Well, I remember how overwhelming UNIX was back when I started. I had a minimal path, and then I started exploring each command as I came across it. If I may quote myself: Manoj The /bin vs /sbin distinction is purely about avoiding Manoj inconvenience and/or confusion for the normal user. The sole Manoj thing accomplished by putting some things in /sbin rather Manoj than /bin is that if you don't put /sbin in your path, you Manoj won't see those things. I myself, probably like most people Manoj on this list, rarely notice the distinction since I do have Manoj /sbin and /usr/sbin in my path. But the idea is that the Manoj average user won't have /sbin or /usr/sbin in their path, and Manoj so the programs in those directories can have simple names Manoj for the convenience of those who do use them, without an Manoj average user either accidentally running one because it has a Manoj simple name they confused with something else, or getting a Manoj lot of confusing possibilities in a command completion list. Manoj The things that we do put in /sbin, for the same reasons, we Manoj expect that the average user will not use them and might be Manoj confused by encountering them. For example, mkfs and fsck Manoj and so forth are in /sbin. Anyone can use these, on a file Manoj or on a device they have permissions for. It's not that we Manoj expect only root to use these, but that we expect anyone who Manoj wanted to use them to probably know enough about the system Manoj to be root (or at least enough more than the average user Manoj that they can handle putting /sbin in their path). Branden So why isn't netstat in sbin? Well, it is an informational program, mostly; route is informational only in oner of it's modes of operation. I would even go out on the limb and say that the primary purpose of route is not to behave like netstat -r. route add/del commands normally do require special priviledges. Branden I think a set of rational and intuitive grounds for Branden determining what goes into sbin is good for everyone. ping Branden is in bin, traceroute is in sbin; netstat is in bin, route Branden is in sbin... Hmm. I shan't defend traceroute, I do think it belongs in /bin. route, though, is something else, as I have explained above. The hueristic that I see glimmering under there seems to be that anything that may affect other users on a multiuser machine out to require sysadmin prviledges. *Sigh*. I wish I had not said that, since now you shall proceed to shoot holes into it. But that is indeed the principle I use in determining whether, in *my* opinion, a program belonfgs in sbin or bin. I admit this criteria is not bullet proof: I have been convinced, by the presence of user mountable entries in /etc/fstab, that mount does belong in /bin; previously I would have argued that mounting and unmounting file systems is not a user task. Another point is that chown/chmod are in /bin, but ifconfig is not; chmod uses file permissions, and an unpriviledged user can't modify files they do not own, and similarily they can't affect interfaces they do not have permission to using ifconfig. The difference, IMO, is that it one can (and people quite frequently do) user chmod on files they own; ifconfig is far less likely to be sued by the general user. (Offhad, I can;t see me useing chown, since one needs permissions anyway for that). No, I do not have hard rules. I do have a a fuzzy guidelines, a well defined (but hard to categorize by) set of goals for the separtion of the path components, traditional placement of commands, and the FHS to go by. And I do think that the goals have merit, even though to experienced users, who frequently are sysadmins, the boundary has become very blurred. You have also, perhaps correctly, classified me as an old fashioned curmudeon who is wildly conservative. Perhaps. I do tend to resist change merely for the sake of change, or for benefits that I believe are unpalpable compared to compatibility and tradition lost. Convince me that the benefits of not having to modify ones path is worth the potential confusion to newbies, and worth losing the imprimatur of FHS compliance by yet another notch, and I'll support doing away with sbin. But so far I ahve not been convinced. Branden Please identify the extrinsic factors that you think trump the Branden characteristics of the actual program. If you are using part of the usage space of
Re: Intent To Split: netbase
Manoj Srivastava [EMAIL PROTECTED] writes: Manoj The /bin vs /sbin distinction is purely about avoiding Manoj inconvenience and/or confusion for the normal user. The sole Actually, this is incorrect. On platforms predating FHS/FSSTND, /sbin was for statically-linked binaries -- versions of vital system tools (fsck, sh, etc) linked statically for repair in an emergency. You may recall I have advocated having a few statically-linked binaries in Debian packages in the past. Manoj thing accomplished by putting some things in /sbin rather Manoj than /bin is that if you don't put /sbin in your path, you Manoj won't see those things. I myself, probably like most people Manoj on this list, rarely notice the distinction since I do have Manoj /sbin and /usr/sbin in my path. But the idea is that the Manoj average user won't have /sbin or /usr/sbin in their path, and Manoj so the programs in those directories can have simple names Manoj for the convenience of those who do use them, without an Manoj average user either accidentally running one because it has a I don't see very many (any?) commands in /sbin that could cause harm to the system, much less the user, if run accidentally by an average non-root user. I think the value is of organizing binaries -- this is why we have a hierarchial filesystem, after all. You have also, perhaps correctly, classified me as an old fashioned curmudeon who is wildly conservative. Perhaps. I do tend to resist change merely for the sake of change, or for benefits that I believe are unpalpable compared to compatibility and tradition lost. I might say that on occasion you tend to resist change merely for the sake of resisting :-) Anyway, I think the current situation is largely fine, although I am still dismayed by the lack of statically-linked binaries in /sbin.
Re: Intent To Split: netbase
On Fri, Aug 18, 2000 at 12:44:37PM -0500, John Goerzen wrote: Anyway, I think the current situation is largely fine, although I am still dismayed by the lack of statically-linked binaries in /sbin. I suppose that's OK too, as long as the binaries are only linked with libs in /lib, which should be on the same partition, and would be available if /sbin was.. Unless somehow only part of the filesystem were damaged, and /lib was inaccessible, but this is most likely not a common situation. --Adam
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 02:05:58PM -0500, Bryan Andersen wrote: When a user or administrator is using it it is because of unusual conditions. Why so? I use it in perfectly usual and common conditions. -- Digital Electronic Being Intended for Assassination and Nullification
Re: mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To Split: netbase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It is much more likely that a normal user will be generating ISO images than ext2 loopback filesystems. - - Original Message - From: Peter S Galbraith [EMAIL PROTECTED] To: debian-devel@lists.debian.org Sent: Thursday, August 17, 2000 4:15 PM Subject: Re: mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To Split: netbase On Thu, 17 Aug 2000, Marcus Brinkmann wrote: There is some inconsistency here. ulysses:~# which mkisofs /usr/bin/mkisofs ulysses:~# which mke2fs /sbin/mke2fs tony mancill wrote: I disagree. You *NEED* to have a copy of mke2fs in the root filesystem in case /usr or any other mounted filesystem gets whacked. OTOH, you probably won't be mastering any CD images while your system is crippled, so having mkisofs in /usr is not inconsistent. Sure. I _think_ Marcus was simply arguing that one command is in a `bin' directory and the other in an `sbin' directory (regardless of the `usr' issue). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.2 for non-commercial use http://www.pgp.com iQA/AwUBOZ3IAgyJYjpYFEaZEQLkAwCdFUVYHBxRUkzz4AVhz1QOOHLItKwAoM3k EcVzWLf0vTUnRo4e1N4zNnVy =khVi -END PGP SIGNATURE-
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 02:05:58PM -0500, Bryan Andersen wrote: Traceroute is a diagnostic command. As such it isn't general use. This distinction between sbin and bin is nowhere defined as having anything to do with general use. When a user or administrator is using it it is because of unusual conditions. My opinion is to leave it in /usr/sbin. Let them type a few extra characters, or add the sbin directories to their path. The same can be said of ping, but ping existed before the bin/sbin split. As such there is legacy code that expects it to be there. Traceroute's been around a long, long time as well. If one really wants it in the general users path, then run a symbolic link back to the original from the appropriate bin directory. This is a lousy fix. | Buzzwords are like annoying little flies that deserve to be swatted. | | -Bryan Andersen| He who quotes himself in his own .signature files likely has no esteem for the views of anyone else, past, present, or future. -me -- G. Branden Robinson |The errors of great men are venerable Debian GNU/Linux|because they are more fruitful than the [EMAIL PROTECTED] |truths of little men. http://www.debian.org/~branden/ |-- Friedrich Nietzsche pgpjs2gLQLPu9.pgp Description: PGP signature
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 05:48:11PM -0500, Steve Greenland wrote: On 16-Aug-00, 12:31 (CDT), Branden Robinson [EMAIL PROTECTED] wrote: Blindly following your fiat declarations about traceroute are getting us into trouble now. What trouble is that? I don't consider having to type /sbin/traceroute or add /sbin to my path trouble. Obviously you haven't typed the actual path to traceroute in quite a while. The constitution clearly says that maintainers have control over their packages. We have agreed that we'll follow Debian policy. Given the lack of policy on this particular topic, Herbert is perfectly within his rights to determine the location of traceroute, unless overridden by the technical committee. There is policy on this topic. We say we will comply with the FHS. (We should probably say we will be compatible instead, else our distribution is literally riddled with FHS violations.) FWIW, I hope that policy won't take this up...detailing the /sbin - /bin location of explicit programs is bound to be an exersize in frustration. Which is why I argued elsewhere to leave this ball in FHS's court. But if we insist on ignoring FHS, we need to have a policy of our own that is more rational than wherever the package maintainer feels like putting it. -- G. Branden Robinson | I've made up my mind. Don't try to Debian GNU/Linux| confuse me with the facts. [EMAIL PROTECTED] | -- Indiana Senator Earl Landgrebe http://www.debian.org/~branden/ | pgpFAkxXeJjmq.pgp Description: PGP signature
Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 09:34:51AM +1000, Herbert Xu wrote: Hmm, I didn't know that traceroute sent ICMP packets by default. Are you sure you are talking about /usr/sbin/traceroute? Point taken. It had been a while since I read the manpage; it uses regular IP packets and manipulates the TTL field. Anyway, from my personal experience, ifconfig/route/ping/traceroute/snmpnetstat are often used together to diagnose problems (or just waste time and bandwidth). Tons of people use ping and traceroute without needing to invoke ifconfig, route, or any form of netstat tool; for instance, when diagnosing routing problems farther away than the interface card in the local machine. If this practice sounds foreign to you, then you either live on a more reliable Internet than I do or are much more indifferent to network problems. -- G. Branden Robinson | A great work of art has never caused any Debian GNU/Linux| social problems. Social problems are [EMAIL PROTECTED] | caused by those trying to protect http://www.debian.org/~branden/ | society from great works of art. pgpQcwGEYM3NT.pgp Description: PGP signature
Re: Intent To Split: netbase
Branden Robinson [EMAIL PROTECTED] wrote:
Anyway, from my personal experience,
ifconfig/route/ping/traceroute/snmpnetstat are often used together to
diagnose problems (or just waste time and bandwidth).
Tons of people use ping and traceroute without needing to invoke ifconfig,
route, or any form of netstat tool; for instance, when diagnosing routing
snmpnetstat will show the routing table of routers that export it
through SNMP. My point is that route in this case is simply a
special case of snpmnetstat.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote: Branden Robinson [EMAIL PROTECTED] wrote: Quoting the FHS: Deciding what things go into sbin directories is simple: If a normal (not a system administrator) user will ever run it directly, then it should be placed in one of the bin directories. Ordinary users should not have to place any of the sbin directories in their path. Note: For example, files such as chfn which users only occasionally use should still be placed in /usr/bin. ping, although it is absolutely necessary for root (network recovery and diagnosis) is often used by users and should live in /bin for that reason. Well, the FHS is contradicting itself here. On one hand, it says that ifconfig is required to be in /sbin, on the other, according to this paragraph, since a user could ocassionally wish to run ifconfig to list the interfaces, it has to be in /bin. Someone should bring this up on the FHS list. Any user who has a legitimate reason to run ifconfig is a system administrator, and thus should have /sbin and /usr/sbin in his path. A user who is running ifconfig out of curiosity is not a systems administrator, and does not need to have it in his path. --Adam
Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 03:27:12AM -0400, Adam McKenna wrote: Any user who has a legitimate reason to run ifconfig is a system administrator, and thus should have /sbin and /usr/sbin in his path. Facilities like /etc/login.defs do discriminate to this fine degree. They know two kinds of user, the ordinary kind and root. They set the path accordingly. With growing attention on capabilities, et al, are we going to tell all Debian users that we only support system administrators who have root? This seems short-sighted and contrary to trends in Unix system administration. A user who is running ifconfig out of curiosity is not a systems administrator, and does not need to have it in his path. How do you define curiosity? Running commands at random, or trying to diagnose a problem so as to send an intelligent problem report to the responsible personnel? -- G. Branden Robinson | It doesn't matter what you are doing, Debian GNU/Linux| emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://www.debian.org/~branden/ | pgpVx4PJy5k5e.pgp Description: PGP signature
Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 02:38:55AM -0500, Branden Robinson wrote: On Thu, Aug 17, 2000 at 03:27:12AM -0400, Adam McKenna wrote: Any user who has a legitimate reason to run ifconfig is a system administrator, and thus should have /sbin and /usr/sbin in his path. Facilities like /etc/login.defs do discriminate to this fine degree. Do you mean, do not discriminate? They know two kinds of user, the ordinary kind and root. They set the path accordingly. It's called .bash_profile. With growing attention on capabilities, et al, are we going to tell all Debian users that we only support system administrators who have root? This seems short-sighted and contrary to trends in Unix system administration. Branden, you have a fantastic ability for rewording other people's statements. I suppose we should tell Debian users that only users who know how to modify their PATH will be able to run binaries in /sbin and /usr/sbin without typing the full path. A user who is running ifconfig out of curiosity is not a systems administrator, and does not need to have it in his path. How do you define curiosity? Running commands at random, or trying to diagnose a problem so as to send an intelligent problem report to the responsible personnel? I don't want anyone who doesn't know how to modify his path troubleshooting a system I admin. They're likely to misdiagnose the problem, overreact to the problem, or perhaps even assume a problem where none exists. At an old job, we once had a user complaining that his network wasn't working because he couldn't ping www.microsoft.com, not knowing that microsoft blocks ICMP echo requests. --Adam
Re: Intent To Split: netbase
On Thu, 17 Aug 2000, Herbert Xu wrote: snmpnetstat will show the routing table of routers that export it through SNMP. My point is that route in this case is simply a special case of snpmnetstat. Most routers have a security arrangement so that the information is not public. Jason
Re: Intent To Split: netbase
On 16-Aug-00, 23:43 (CDT), Branden Robinson [EMAIL PROTECTED] wrote: On Wed, Aug 16, 2000 at 05:48:11PM -0500, Steve Greenland wrote: What trouble is that? I don't consider having to type /sbin/traceroute or add /sbin to my path trouble. Obviously you haven't typed the actual path to traceroute in quite a while. Exactly. I put /sbin in my path and stopped worrying about it. There is policy on this topic. We say we will comply with the FHS. (We should probably say we will be compatible instead, else our distribution is literally riddled with FHS violations.) I think the location of traceroute is ambiguous. (I also agree that the FHS is itself confused on this topic, as has been pointed out elsewhere.) Steve
Re: Intent To Split: netbase
Marcus == Marcus Brinkmann [EMAIL PROTECTED] writes: Marcus We can put everything in /bin and make /sbin a link to /bin. Marcus This way the utilities the FHS liste can be found in /sbin, Marcus but there physical place is elsewhere. This does not violate Marcus the standard. I still think there is merit in having a separate path component for things that are not very useful when I do not have my sysadmin hat on. Indeed, there are a number of machines on which I do not have priviledges, and there is a special division for admins who take strong exeption to things being mucked around behind their backs. On these machines I do not need ifconfig -- and I know where to get them should I need them for diagnostics -- I just pick the phone and call someone to have the problem resolved. I think there is a large contingent of users out there who are not even part time sysadmins. Why is it so hard for sysadmins and part tiem sysadmins to enhance their path? I think that FHS compliance, and uniformity with other Linux distributions is important as well. manoj -- Engineering: How will this work? Science: Why will this work? Management: When will this work? Liberal Arts: Do you want fries with that? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 14.08.00 in [EMAIL PROTECTED]: John == John Goerzen [EMAIL PROTECTED] writes: No real reason? Only one package can listen in on port 25, and John There is no real reason that all must listen on port 25. Then you and I have very different opinions on what a working MTA is. Indeed, the SMTP RFC's differ with your opinion as well AFAIK most MTAs can be convinced to use a different port. I wonder why that is? I know that Exim has support to talk to a SMTP server on an arbitrary port. I see no reason to assume other MTAs can't do the same. I wonder why that is? I have a machine running two different Exim konfigurations at the same time, one not involving listening on any port. Separate spools, separate logs. I wonder why one of those couldn't be a different MTA? As for NNTP, you've heard of port nntps? And then there's the option of running server-to-server NNTP on arbitrary ports. John These aren't real reasons at all. Given that, you have a curious definition of ``real''. Unfortunately, I do not think I find your definition of real very interesting. His seems to be about the same as mine. Your real reasons boil down to I don't know why you'd want to do that, which is a piss-poor reason for *anything*. One should optimize for the most common case. I think people The rule should be: make easy things easy, and make hard things possible. who can maneuver around the port numbers can also recompile or use dpkg -x effectively. There's a rather big difference between putting demon_smtp_port=1234 into a config and those other options. I am unsure that the results are quite worth the effort that needs be expended. One rather common case with MTAs is switching from one to another with a non-empty spool. Rather hard when they don't coexist peacefully. You don't even need alternate ports for that - only the new MTA needs to actually run a SMTP listener, the old one only needs a queue runner. MfG Kai
Re: Intent To Split: netbase
[EMAIL PROTECTED] (Adrian Bridgett) wrote on 16.08.00 in [EMAIL PROTECTED]: On Wed, Aug 16, 2000 at 12:31:47 -0500 (+), Branden Robinson wrote: On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote: Well, the FHS is contradicting itself here. On one hand, it says that ifconfig is required to be in /sbin, on the other, according to this paragraph, since a user could ocassionally wish to run ifconfig to list the interfaces, it has to be in /bin. Someone should bring this up on the FHS list. I agree with that much. [snip] What so wrong with user tools in */bin and sysadmin tools in */sbin. Nothing, if the definition of user tools matches the FHS /bin - /sbin distinction, which says that if users ever run the thing, it belongs in /bin. As an advanced user, I always put /sbin and /usr/sbin in my PATH, whatever the unix I'm on. And the FHS *explicitely* says you shouldn't have to. People who know about ifconfig should know enough to add /sbin and /usr/sbin to their PATH IMO. And the FHS *explicitely* says they shouldn't have to. MfG Kai
Re: Intent To Split: netbase
[EMAIL PROTECTED] (Jacob Kuntz) wrote on 15.08.00 in [EMAIL PROTECTED]: Clint Adams ([EMAIL PROTECTED]) wrote: No real reason? Only one package can listen in on port 25, and Only one package can listen on port 25 of one IP. It is possible to have multiple packages listening on different ports or different IPs. hadn't thought of that. but once again, is there any benefit to that at all? will the efort required by the maintainers to get this working properly (including reading bug reports) ever balance against the tiny number of people that would use this feature? anyone that has a reason can certianly set this up themselves. *Is* there significant effort needed from the maintainers? At least for the case of Exim, I suspect the effort reduces to a trivial edit of debian/control iff you accept that people installing more than one MTA have to create a sane configuration manually. And I suspect it's not really different for other MTAs. MfG Kai
Re: Intent To Split: netbase
Joey == Joey Hess [EMAIL PROTECTED] writes: As to mount telling us what is mounted, so does df, and cat /etc/mtab. again, not enough to move mount; unless one is being contrary. Joey I dont follow this. 'echo *' can tell me what files are in a directory; Joey a system without ls in path is still broken. You are missing the point. The point is not that if *any* arcane alternative exists we should move a program out of /bin; the pooint is that if a progrom in sbin has a usage that a normal user _may_ find interesting is not enough reason to move it out of sbin, espescially if there are other mehtods of accomplishing the same using programs already in /bin. Joey I don't see how mount is much different. Regular users *often* Joey want to mount/unmount/check mount status of removable Joey media. And it's in /bin now, so isn't this a red herring Joey anyway? We are trying to determine rationale, and thus even things that are in their appropriate place in the file system are fair game for analysis. The point I was making is that trying to find mounted file systems is not the reason to move mount out of /sbin. The user mountable removeable media, on the other hand, is an excellent reasdon, and thus mount is in /bin. The /bin vs /sbin distinction is purely about avoiding inconvenience and/or confusion for the normal user. The sole thing accomplished by putting some things in /sbin rather than /bin is that if you don't put /sbin in your path, you won't see those things. I myself, probably like most people on this list, rarely notice the distinction since I do have /sbin and /usr/sbin in my path. But the idea is that the average user won't have /sbin or /usr/sbin in their path, and so the programs in those directories can have simple names for the convenience of those who do use them, without an average user either accidentally running one because it has a simple name they confused with something else, or getting a lot of confusing possibilities in a command completion list. The things that we do put in /sbin, for the same reasons, we expect that the average user will not use them and might be confused by encountering them. For example, mkfs and fsck and so forth are in /sbin. Anyone can use these, on a file or on a device they have permissions for. It's not that we expect only root to use these, but that we expect anyone who wanted to use them to probably know enough about the system to be root (or at least enough more than the average user that they can handle putting /sbin in their path). manoj -- The sooner all the animals are extinct, the sooner we'll find their money. Ed Bluestone Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 10:42:57AM -0500, Steve Greenland wrote: On 16-Aug-00, 23:43 (CDT), Branden Robinson [EMAIL PROTECTED] wrote: On Wed, Aug 16, 2000 at 05:48:11PM -0500, Steve Greenland wrote: What trouble is that? I don't consider having to type /sbin/traceroute or add /sbin to my path trouble. Obviously you haven't typed the actual path to traceroute in quite a while. Exactly. I put /sbin in my path and stopped worrying about it. Well, technically, no, you didn't. You put something else in your path and stopped worrying about it. -- G. Branden Robinson |Convictions are more dangerous enemies Debian GNU/Linux|of truth than lies. [EMAIL PROTECTED] |-- Friedrich Nietzsche http://www.debian.org/~branden/ | pgpuPRn5hpt6n.pgp Description: PGP signature
Re: Intent To Split: netbase
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden There is policy on this topic. We say we will comply with Branden the FHS. (We should probably say we will be compatible Branden instead, else our distribution is literally riddled with FHS Branden violations.) Should we not rather make an attempt to get rid of some of those incompatibilities, rather than throwing our hands in disgust and punting on it before we even start? manoj -- Depends on how you define always. :-) Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden Well, keep in mind that Debian has committed itself to Branden FHS-compatibility, not FHS-compliance. This means that we Branden are free to have symlinks standing between a pathname and Branden the inode. We have? That's news to me. == sect1 headingLinux File system Structure/heading p The location of all installed files and directories must comply with the Linux File system Hierarchy Standard (FHS). The latest version of this document can be found alongside this manual or on url id=http://www.pathname.com/fhs/;.footnote pThe Debian distribution currently distributes a draft version of FHS 2.1 because several significant details have changed between the currently released 2.0 version and the to-be-released 2.1 version./p /footnote Specific questions about following the standard may be asked on prgndebian-devel/prgn, or referred to Daniel Quinlan, the FHS coordinator, at email[EMAIL PROTECTED]/email./p/sect1 == You could have fooled me ;-) manoj -- The most delightful day after the one on which you buy a cottage in the country is the one on which you resell it. Brecheux Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden On Wed, Aug 16, 2000 at 10:53:51AM -0400, Raul Miller wrote: d) they don't know about an alternative command which is already in their path. [For example: netstat -er gives the same information as route.] Branden I don't think it's feasible for a standards body or a Branden package maintainer to make case-by-decisions on the location Branden of a tool based upon the functionality of every other tool Branden that might provide that functionality. Taken to extremes, no. Branden This would lead to an unstable environment, where the Branden presence of route in bin would justified if and only if Branden nothing else could show you the routing tables. This would I think I disagree here. Instead of laying down the law like this, I would rather leave things fuzzy, and rely on common sense; just because route provides routing information shoul not be enough to move it out of sbin (I am sure one can come up with some reason for moving every single probgram out of sbin, and thus lose all the benefits of the split). Branden also differ on a system-by-system basis as users have Branden different packages installed. Should route go into bin for Branden users that (somehow) don't have netstat installed, but sbin Branden for users that do? It makes no sense. route is in sbin. period. If people wat to see the current routing status, they have two options: a) add /sbin to your path, or type in the full path name b) install netstat. You can't please veryone all the time. In attempting to please the semi-sysadmin power user you are going to remove a feature that benefits the absolute novice. Any semi-sysadmin/power user types should also be knowledegable enough to modify their path variables. Or create an alias. Or a symlink. Indeed, if you use it often enough, _do_ change the path. But do not assume that what is good for you is good for everyone else. Branden In other words, I think the choice of directory should be Branden controlled by factors intrinsic, not extrinsic, to the Branden program in question. To a point. But I think making this an absolute rule is going too far. manoj -- I saw a subliminal advertising executive, but only for a second. Steven Wright Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
Anthony Towns wrote: FHS discuss people: where should traceroute go? Tradition dictates /usr/sbin, the FHS seems to indicate /usr/bin would be more appropriate. I think it should be in /usr/bin, certainly if it is setuid. So should ping, and mount and umount. It is most annoying if you insert a floppy or cd-rom as a user, read it through a well-known automount point such as /misc/cdrom, and then cannot extract it anymore because: /misc/cdrom is not in /etc/fstab and you are not root - the error message that umount spits out on Linux when a non-root user tries umount and the filesystem does not have the user attribute in /etc/fstab, par force because /misc/cdrom was not listed at all. ifconfig is also necessary for users: A user types telnet blahblah, the system dials out, acquires an IP address, and then the user will want to set the DISPLAY variable on the remote system. If that remote system does not discover automatically, then ifconfig is one way to find out. Many tasks that were traditionally reserved for the administrator are no longer so, or not in all cases. If Linux (Unix) wants to make an impact on end user systems, it has to cater for users which: o know little about how to administrate a Linux system o do not want to know o pay $50 call-out charge for a system administrator o pay $1 a minute for telephone support Such a callout charge may be acceptable if you switch on the system and it tells you the filesystem is corrupt, you should check it. But to extract a CD-Rom ? Would you buy a washing machine where you need to call out an electrician to switch it on ? I know rebooting is a dirty word in the Linux and Unix community, but anything that can with good probability be achieved by rebooting or power-cycling the machine should not require a system administrator. The appropriate commands should have a setuid mode that prevents some of the more obvious ways to create havoc - such as ping fretting on non-root requestetd flood pings. Thomas * Why not use metric units and get it right first time, every time ? * * email: cmaae47 @ imperial.ac.uk * voice: +4420-7594-6912 (day) * fax: +4420-7594-6958 * snail: Thomas Sippel - Dau * Linux Services Manager * Imperial College of Science, Technology and Medicine * The Center for Computing Services * Exhibition Road * Kensington SW7 2BX * Great Britain
Re: Intent To Split: netbase
Kai == Kai Henningsen [EMAIL PROTECTED] writes: Kai AFAIK most MTAs can be convinced to use a different port. I Kai wonder why that is? You are missing the point. How often do these things have to be done? How difficult is it to install two different MTA's as things stand? Kai I know that Exim has support to talk to a SMTP server on an Kai arbitrary port. I see no reason to assume other MTAs can't do Kai the same. I wonder why that is? If you do not know, I do not think you should really be participating in this discussion. If you do know, you perhsaps should not be participating here with this inflamatory stance either. Kai I have a machine running two different Exim konfigurations at Kai the same time, one not involving listening on any port. Separate Kai spools, separate logs. I wonder why one of those couldn't be a Kai different MTA? And how commohn a practice do you think that is? Kai As for NNTP, you've heard of port nntps? And then there's the Kai option of running server-to-server NNTP on arbitrary ports. How common is this? John These aren't real reasons at all. Given that, you have a curious definition of ``real''. Unfortunately, I do not think I find your definition of real very interesting. Kai His seems to be about the same as mine. Your real reasons boil Kai down to I don't know why you'd want to do that, which is a Kai piss-poor reason for *anything*. Bullshit. You have totally missed the point of my message, and have the gall to come in with a cendescending flammage that is ill condusive to any further discussion. Until you show you have the basic understanding of what is called the common case, I have nothing to say to you. manoj and we were too having a reasoably sane discussion until now -- I don't think I'm gonna agree with that. Way too much visual confusion... Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
Kai == Kai Henningsen [EMAIL PROTECTED] writes: Kai Nothing, if the definition of user tools matches the FHS /bin - /sbin Kai distinction, which says that if users ever run the thing, it belongs in Kai /bin. I think there is a modicum on common sense expetced to be applied here. If a user ever runs fsck, halt, lilo, or any other program in /sbin, should they automatcally move out of there? (note there is not mention of succesfully run). This is a fuzzy are, unfortunately for rules lawyers, and one is supposed to use common sense, a feeling of how often an ordinary user may use a program, whether they really need to, are they wearing a sysadmin hat, and cater to the views of newbies. I also do not think it is going to be possible to please all the people all the time. As an advanced user, I always put /sbin and /usr/sbin in my PATH, whatever the unix I'm on. Kai And the FHS *explicitely* says you shouldn't have to. Umm, I think he is defining himself not to be the common user, and the FHS explicitly says he should. People who know about ifconfig should know enough to add /sbin and /usr/sbin to their PATH IMO. Kai And the FHS *explicitely* says they shouldn't have to. Not quite. (or else quote chapter and verses where the FHS explicitly says anyone who knows about ifconfig does not have to pout /sbin and /usr/sbin in their path (you do know what explicit means, don't you?) manoj == See, this actually runs for me as a user: __ /sbin/lilo -h usage: lilo [ -C config_file ] -q [ -m map_file ] [ -v ... ] lilo [ -C config_file ] [ -b boot_device ] [ -c ] [ -l | -L ] [ -i boot_sector ] [ -m map_file ] [ -d delay ] [ -v ... ] [ -t ] [ -s save_file | -S save_file ] [ -P fix | -P ignore ] [ -r root_dir ] [ -w ] lilo [ -C config_file ] [ -m map_file ] -R [ word ... ] lilo [ -C config_file ] -I name [ options ] lilo [ -C config_file ] [ -s save_file ] -u | -U [ boot_device ] lilo -V == -- If we see the light at the end of the tunnel, it's the light of an oncoming train. Robert Lowell Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 11:39:23AM -0500, Manoj Srivastava wrote: Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden Well, keep in mind that Debian has committed itself to Branden FHS-compatibility, not FHS-compliance. This means that we Branden are free to have symlinks standing between a pathname and Branden the inode. We have? That's news to me. [...] You could have fooled me ;-) Yes, at the time I posted this I misremembered a proposed policy amendement as an accepted one. I think if you catch up on debian-policy you'll see that I have corrected my error. -- G. Branden Robinson |There's nothing an agnostic can't do Debian GNU/Linux|if he doesn't know whether he believes [EMAIL PROTECTED] |in it or not. http://www.debian.org/~branden/ |-- Graham Chapman pgp65zGXR1omP.pgp Description: PGP signature
Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 11:35:31AM -0500, Manoj Srivastava wrote: Should we not rather make an attempt to get rid of some of those incompatibilities, rather than throwing our hands in disgust and punting on it before we even start? Have fun hacking apt. -- G. Branden Robinson |Any man who does not realize that he is Debian GNU/Linux|half an animal is only half a man. [EMAIL PROTECTED] |-- Thornton Wilder http://www.debian.org/~branden/ | pgpumd8nxXlkU.pgp Description: PGP signature
Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 11:48:06AM -0500, Manoj Srivastava wrote: (I am sure one can come up with some reason for moving every single probgram out of sbin, and thus lose all the benefits of the split). Could you remind me what these benefits are again? Pretend for a moment that the FHS doesn't exist and it's entirely up to us. What exactly DO we gain by having some binaries segregated off into sbin? route is in sbin. period. This begs the question. If people wat to see the current routing status, they have two options: a) add /sbin to your path, or type in the full path name b) install netstat. So why isn't netstat in sbin? You can't please veryone all the time. In attempting to please the semi-sysadmin power user you are going to remove a feature that benefits the absolute novice. Again, please tell me what these benefits are. Do you have anything approaching quantifiable data or a testable hypothesis? Any semi-sysadmin/power user types should also be knowledegable enough to modify their path variables. Or create an alias. Or a symlink. Indeed, if you use it often enough, _do_ change the path. But do not assume that what is good for you is good for everyone else. I think a set of rational and intuitive grounds for determining what goes into sbin is good for everyone. ping is in bin, traceroute is in sbin; netstat is in bin, route is in sbin... Branden In other words, I think the choice of directory should be Branden controlled by factors intrinsic, not extrinsic, to the Branden program in question. To a point. But I think making this an absolute rule is going too far. Please identify the extrinsic factors that you think trump the characteristics of the actual program. -- G. Branden Robinson | Religion is something left over from the Debian GNU/Linux| infancy of our intelligence; it will [EMAIL PROTECTED] | fade away as we adopt reason and science http://www.debian.org/~branden/ | as our guidelines. -- Bertrand Russell pgpNSWbbjN139.pgp Description: PGP signature
Re: Intent To Split: netbase
On Tue, Aug 15, 2000 at 06:54:24AM -0700, Joey Hess wrote: The question that seems to want to be raised is whether this is true? Are people really confused more by having extra commands available, or are they confused by _not_ havingcertain commands present? Sounds fine to me. The irony is, of course, that the people generally making such decisions (like this forum) are rarely a decent sampling of the user base, or the hypothetical Joe user. Maybe we should ask our users then? Greetings from a lurking user, me user-hat=on I startef using debian about 3 years ago. One of the first things that I really liked was bash tab completion. I had to guess at commands because I didn't know what they were named but, I guessed that the functionality should be there. One of my first modifications was to add directories of most(all?) executables to my path. I find it _very annoying_ to NOT get tab completion on commands that I now know exist when I am on another system. me user-hat=off me sys-admin-hat=on I now get paid for my knowledge of Gnu/Linux (more specifically Debian). and the majority of the people that I set up systems for are either CS students who need to know as much as possible or simple users of services like email, http, ftp, samba, etc.. Either way, having everything available is prefered. On machines that users shouldn't have these commands I simply don't give them user accounts. On less critical machines, whocares what they do to it, they will learn judicious use eventually. The *evil* user is an extremly rare animal in my arena (academia), at least so far protector-talisman=on. :-) me sys-admin-hat=off Hopefully this info is usefull to this debate, if not I apologize. By the way, kudos to everyone on yet another excellent release of Debian! -- Frisco Rose By any other name, I would smell the same E.O.U. Stud. [EMAIL PROTECTED] [EMAIL PROTECTED] Physics Mathematics Computer Science If all the ipv6 addresses were distributed evenly across the planets surface, there would be roughly 423,354,243,695,259,002,656 per square inch. And, no, I don't know what this has to do with anything.
mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 11:26:17AM -0500, Manoj Srivastava wrote: The things that we do put in /sbin, for the same reasons, we expect that the average user will not use them and might be confused by encountering them. For example, mkfs and fsck and so forth are in /sbin. Anyone can use these, on a file or on a device they have permissions for. It's not that we expect only root to use these, but that we expect anyone who wanted to use them to probably know enough about the system to be root (or at least enough more than the average user that they can handle putting /sbin in their path). There is some inconsistency here. ulysses:~# which mkisofs /usr/bin/mkisofs ulysses:~# which mke2fs /sbin/mke2fs And note that one can burn any filesystem on a CD (if you are allowed to access the CD writer). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To Split: netbase
On Thu, 17 Aug 2000, Marcus Brinkmann wrote: On Thu, Aug 17, 2000 at 11:26:17AM -0500, Manoj Srivastava wrote: The things that we do put in /sbin, for the same reasons, we expect that the average user will not use them and might be confused by encountering them. For example, mkfs and fsck and so forth are in /sbin. Anyone can use these, on a file or on a device they have permissions for. It's not that we expect only root to use these, but that we expect anyone who wanted to use them to probably know enough about the system to be root (or at least enough more than the average user that they can handle putting /sbin in their path). There is some inconsistency here. ulysses:~# which mkisofs /usr/bin/mkisofs ulysses:~# which mke2fs /sbin/mke2fs I disagree. You *NEED* to have a copy of mke2fs in the root filesystem in case /usr or any other mounted filesystem gets whacked. OTOH, you probably won't be mastering any CD images while your system is crippled, so having mkisofs in /usr is not inconsistent. The reason that mkisofs is not in /sbin is because /sbin should be reserved for things the core OS needs to have all of the time on the root partition. If you start putting mkisofs and the like in /sbin, then you have the problem of / growing over time. If you put mke2fs in /usr, then you're going to wish that you hadn't one day. I'm not sure that I understand this entire thread. Much of where files go is based on history/tradition, and like it or not, most of Linux/Debian's heritage is based on how the various Unices have solved certain problems over the past 25 years or so. Change is good, but only when folks understand why they're changing things, insted of being too lazy to add something to their PATH or learn where (and *why*) commands are where they are. (Sorry, this really isn't intended to flame anyone, but it seems that -devel gets off on the weirdest tangents sometimes.) tony [EMAIL PROTECTED] | Time after time we lose sight of the way. http://www.debian.org | Our causes can't see their effects. | (Neil Peart)
Re: mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To Split: netbase
On Thu, 17 Aug 2000, Marcus Brinkmann wrote: There is some inconsistency here. ulysses:~# which mkisofs /usr/bin/mkisofs ulysses:~# which mke2fs /sbin/mke2fs tony mancill wrote: I disagree. You *NEED* to have a copy of mke2fs in the root filesystem in case /usr or any other mounted filesystem gets whacked. OTOH, you probably won't be mastering any CD images while your system is crippled, so having mkisofs in /usr is not inconsistent. Sure. I _think_ Marcus was simply arguing that one command is in a `bin' directory and the other in an `sbin' directory (regardless of the `usr' issue).
Re: mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To Split: netbase
On Thu, Aug 17, 2000 at 04:15:17PM -0400, Peter S Galbraith wrote: On Thu, 17 Aug 2000, Marcus Brinkmann wrote: There is some inconsistency here. ulysses:~# which mkisofs /usr/bin/mkisofs ulysses:~# which mke2fs /sbin/mke2fs tony mancill wrote: I disagree. You *NEED* to have a copy of mke2fs in the root filesystem in case /usr or any other mounted filesystem gets whacked. OTOH, you probably won't be mastering any CD images while your system is crippled, so having mkisofs in /usr is not inconsistent. Sure. I _think_ Marcus was simply arguing that one command is in a `bin' directory and the other in an `sbin' directory (regardless of the `usr' issue). Peter is correct. mke2fs could be in /bin without conflicting with what Tony (rightfully) said. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Intent To Split: netbase
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony ifconfig is a required file for /sbin according the the FHS Anthony section 3.10 as distributed in the debian-policy package. I think that some people are espousing non-compliance with the standards. Is that what we want to do? Steve OK, how about moving everything into /bin except what FHS Steve specifically says should be in /sbin? Section 3.10[0] Steve identifies the following specifically to be located in /sbin: Sounds like a cop out. We are acknowledging that we can no longer come to a consensus on this, and we are punting on this. Actually, it may be closer to saying we really don't like sbin, and we move everything out of there, except that we also want to be FHS compliant, and let just tose programs stay in. I think we should either a) categorize the programs, by extending the reasoning of the FHS, and I have not yet lost hope of our ability to reach a rough consensus, b) decide that the sbin idea is silly, and that's that (we can symlink /sbin to /bin) I think we may be truthfully accused of losing touch with the generic user out there. Most of the discusion here (and, I confess, my knee jerk reactions), have dealt with the issue with opinions on what works for us -- even though developers are rarely a decent sampling of the unwashed masses. My experience has been that most users, even most linux users, are not what the industry terms ``power users'' (most of these folks just call the sys admin when things go wrong). The defaults should be designed around them, not us, since power users shall always tweak the system defaults anyway. manoj stepping off the soap box -- A good teacher has been defined as one who makes himself progressively unnecessary. -- Thomas J. Carruthers Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
I proposed using symlinks for programs in */sbin to enable normal users to see them in their default path, but now I think this is a bit messy. (For instance, /sbin/ifconfig - /bin/ifconfig, lots of these would be ad hoc) For simplicity's sake, I think it's just good enough to include /sbin, /usr/sbin and /usr/local/sbin in user's default path. That way, filesystem standard compliance is not disturbed, and the users have those programs in their path by default. Thanks, __ Eray Ozkural
Re: Intent To Split: netbase
On Tue, Aug 15, 2000 at 05:07:25PM -0400, Decklin Foster wrote: Steve Bowman writes: OK, how about moving everything into /bin except what FHS specifically says should be in /sbin? snip list from FHS 3.10 I very much like this idea. Does anyone have objections? I don't object. I still think a few of those tools could profitably be placed in (/usr)?/bin, but this is at least another step closer to the elimination of a useless artifact of the old days. -- G. Branden Robinson | Debian GNU/Linux| Never attribute to malice that which can [EMAIL PROTECTED] | be adequately explained by stupidity. http://www.debian.org/~branden/ | pgpxXbDoKJWY4.pgp Description: PGP signature
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 07:32:32AM +1000, Herbert Xu wrote: Branden Robinson [EMAIL PROTECTED] wrote: On Tue, Aug 15, 2000 at 05:55:38PM +1000, Herbert Xu wrote: But I thought one of the main complaints was that /usr/sbin wasn't in the PATH. Generally, maintainer scripts, and programs meant to be run by root, run as root. If a program expects to use some tool that only root would use, it should expect to be running as root. So you do agree with me that it is better to leave traceroute in /usr/sbin? Uh, no. My remarks above in fact strong imply the opposite conclusion. (However, I don't think traceroute is the strongest candidate for a program that gets run from inside a script.) -- G. Branden Robinson |Communism is just one step on the long Debian GNU/Linux|road from capitalism to capitalism. [EMAIL PROTECTED] |-- Russian saying http://www.debian.org/~branden/ | pgp4XPWzEfaJx.pgp Description: PGP signature
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 12:39:15PM +1000, Anthony Towns wrote: On Wed, Aug 16, 2000 at 01:12:58AM +0300, Eray Ozkural wrote: I was confused by not having ifconfig in my user path. On this machine, there's only a dial-up net connection, and it has some small connectivity problems. I need to check whether the line's really up. I found myself going super-user to issue the command rather than running /sbin/ifconfig. ifconfig is a required file for /sbin according the the FHS section 3.10 as distributed in the debian-policy package. Well, keep in mind that Debian has committed itself to FHS-compatibility, not FHS-compliance. This means that we are free to have symlinks standing between a pathname and the inode. -- G. Branden Robinson | Debian GNU/Linux| Music is the brandy of the damned. [EMAIL PROTECTED] | -- George Bernard Shaw http://www.debian.org/~branden/ | pgpxK72VpIVS1.pgp Description: PGP signature
Re: Intent To Split: netbase
[Followups to debian-policy, please] On Tue, Aug 15, 2000 at 11:22:11PM -0500, Manoj Srivastava wrote: I think that some people are espousing non-compliance with the standards. Is that what we want to do? The FHS exhaustively explains the difference between compatibility and compliance. I note that the Debian policy manual says that all installed files and directories must comply with the FHS, rather than must be compatible with the FHS. Let this message serve as policy proposal that we change the wording of section 3.1.1 from must comply to must be compatible. This change needs to be made irrespective of any consensus (or lack thereof) on the issue moving binaries from (/usr)?/sbin to (/usr)?/bin, because we continue to carry around relics of non-FHS-compliance (such as /var/state) that may take quite some time to dislodge. (Witness the /usr/share/doc migration.) Furthermore, the footnote following the URL of the FHS should probably be deleted, since FHS 2.1 is no longer in draft status. Steve OK, how about moving everything into /bin except what FHS Steve specifically says should be in /sbin? Section 3.10[0] Steve identifies the following specifically to be located in /sbin: Sounds like a cop out. We are acknowledging that we can no longer come to a consensus on this, and we are punting on this. Actually, it may be closer to saying we really don't like sbin, and we move everything out of there, except that we also want to be FHS compliant, and let just tose programs stay in. I can agree with either interpretation, though I disagree with your characterization of the former as a cop out. The traceroute argument comes up over and over again. The defenders of the status quo have no defense for the inconsistency between having one traceroute tool in sbin and a different one in bin. Rather than having one of the programs move, they just tell people to change their $PATH. This does not indicate to me the slightest motivation to extend the reasoning of the FHS. The FHS team has given themselves a mandate to sort these issues out. Let them. Why should we argue about whether a certain binary goes in one directory or the other when it's a much bigger part of their mission statement to make that decision than ours? FHS is an open standards group, more to the point, so Debian developers who feel passionately about such things can join it and carry on their flamewars there. I think we should either a) categorize the programs, by extending the reasoning of the FHS, and I have not yet lost hope of our ability to reach a rough consensus, I think it's the FHS's job to delimit its own reasoning. There are places where it defers to vendors. b) decide that the sbin idea is silly, and that's that (we can symlink /sbin to /bin) Well, that's my personal feeling, but I don't think one needs to feel this way to know that the appropriate place for traceroute is not sbin. I think we may be truthfully accused of losing touch with the generic user out there. I think the generic user neither knows nor cares about the distinction between bin and sbin. There's also no reason to fence him off from harmless and even useful commands. Quoting the FHS: Deciding what things go into sbin directories is simple: If a normal (not a system administrator) user will ever run it directly, then it should be placed in one of the bin directories. Ordinary users should not have to place any of the sbin directories in their path. Note: For example, files such as chfn which users only occasionally use should still be placed in /usr/bin. ping, although it is absolutely necessary for root (network recovery and diagnosis) is often used by users and should live in /bin for that reason. -- G. Branden Robinson |Software engineering: that part of Debian GNU/Linux|computer science which is too difficult [EMAIL PROTECTED] |for the computer scientist. http://www.debian.org/~branden/ | pgpjfu0lVrcA4.pgp Description: PGP signature
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 09:23:11AM +0300, Eray Ozkural wrote: For simplicity's sake, I think it's just good enough to include /sbin, /usr/sbin and /usr/local/sbin in user's default path. I think if someone has to do such a thing, then: a) they forgot to su root; or b) they don't know they need privleges to use the command in question; or c) the command doesn't belong in sbin anyway. -- G. Branden Robinson | When dogma enters the brain, all Debian GNU/Linux| intellectual activity ceases. [EMAIL PROTECTED] | -- Robert Anton Wilson http://www.debian.org/~branden/ | pgpZM7E8ILttb.pgp Description: PGP signature
Re: Intent To Split: netbase
Branden Robinson [EMAIL PROTECTED] wrote:
Quoting the FHS:
Deciding what things go into sbin directories is simple: If a normal
(not a system administrator) user will ever run it directly, then it
should be placed in one of the bin directories. Ordinary users should
not have to place any of the sbin directories in their path.
Note: For example, files such as chfn which users only occasionally use
should still be placed in /usr/bin. ping, although it is absolutely
necessary for root (network recovery and diagnosis) is often used by
users and should live in /bin for that reason.
Well, the FHS is contradicting itself here. On one hand, it says that
ifconfig is required to be in /sbin, on the other, according to this
paragraph, since a user could ocassionally wish to run ifconfig to list
the interfaces, it has to be in /bin. Someone should bring this up on
the FHS list.
Blindly following a contradictory standard is only going to get us into
trouble later on.
Just to rephrase my main reason for not moving traceroute, it's a tool that
is in the same category as ping/ifconfig/route, i.e., it's a network
diagnostic tool. On Linux, ping has traditionally been in /bin while the
other three have always lived in /sbin and /usr/sbin, respectively. Unless
there is a very good reason (for the convenience of users who should really
be changing their PATH variable is not good enough IMHO), we shouldn't move
these things around as LOCAL scripts may depend on them.
Now if a later version of the FHS unequivocally stated that all these tools
should be in /bin or /usr/bin, and as a project we decide to do that, then
we can carry out such a change in a way not dissimilar to how things were
moved around when the FSSTND first came about.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Intent To Split: netbase
FHS discuss people: where should traceroute go? Tradition dictates /usr/sbin, the FHS seems to indicate /usr/bin would be more appropriate. On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote: Blindly following a contradictory standard is only going to get us into trouble later on. Just to rephrase my main reason for not moving traceroute, it's a tool that is in the same category as ping/ifconfig/route, i.e., it's a network diagnostic tool. `ifconfig' and `ping' aren't really in the same category, though. ifconfig (like route, mount, and like modprobe or lsmod) acts on local hardware, whereas ping (like traceroute, and arguably telnet or nc) is commonly used as a tool to investigate distant sites. Toying with local stuff is the system administrator's playground, by definition, but investigating remote hosts is a reasonable thing to expect both admins and users to do. This seems to me to match at least the spirit of the FHS's definition of sbin: ] Deciding what things go into sbin directories is simple: If a normal ] (not a system administrator) user will ever run it directly, then it ] should be placed in one of the bin directories. Ordinary users should ] not have to place any of the sbin directories in their path. This definition is really quite poor if you put too much emphasis on the ever. swapon, for example, is clearly a tool for the admin, but a user might decide one day to run it just see which version of the program is installed on the system. mount, and ifconfig are less extreme versions of the same thing: a normal user can't use it to actually *do* anything, just to find out something about the way the system's setup, which is something of an admin task. ping and traceroute, by contrast are almost completely as useful for a normal user as root. On Linux, ping has traditionally been in /bin while the other three have always lived in /sbin and /usr/sbin, respectively. This is probably enough reason for the FHS to explicitly state where traceroute should go, since /usr/sbin seems in conflict with the earlier definition of sbin. Unless there is a very good reason (for the convenience of users who should really be changing their PATH variable is not good enough IMHO), we shouldn't move these things around as LOCAL scripts may depend on them. Similarly for /var/mail, /usr/lib/sendmail, /usr/doc, and so on, albeit perhaps to a lesser extent. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpLlDTenK12w.pgp Description: PGP signature
Re: Intent To Split: netbase
On 15-Aug-00, 17:12 (CDT), Eray Ozkural [EMAIL PROTECTED] wrote: I was confused by not having ifconfig in my user path. On this machine, there's only a dial-up net connection, and it has some small connectivity problems. I need to check whether the line's really up. I found myself going super-user to issue the command rather than running /sbin/ifconfig. I can see that typing 'sudo ifconfig' might be easier than '/sbin/ifconfig', depending on how one's fingers are wired. What I cannot figure out is why typing 'ln -s /sbin/ifconfig ~/bin' *once* is not easier than either... Steve
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 09:23:11AM +0300, Eray Ozkural wrote: For simplicity's sake, I think it's just good enough to include /sbin, /usr/sbin and /usr/local/sbin in user's default path. On Wed, Aug 16, 2000 at 02:42:37AM -0500, Branden Robinson wrote: I think if someone has to do such a thing, then: a) they forgot to su root; or b) they don't know they need privleges to use the command in question; or c) the command doesn't belong in sbin anyway. While I agree with your thinking, I think you've left out a case: d) they don't know about an alternative command which is already in their path. [For example: netstat -er gives the same information as route.] While I'm on this subject, I should mention: the man page for the netstat in netbase 3.18-1 claimed: netstat -ei will print a table or a single interface entry just like ifconfig does. This is true for the netstat in net-tools 1.57-1, but was blatantly false for the netstat that came with netbase. Strangely, the manpage in net-tools doesn't document this behavior (nor the netstat -er behavior). I wonder if this new lack of documentation should be considered a bug? -- Raul
Re: Intent To Split: netbase
On Tue, Aug 15, 2000 at 12:18:14PM -0700, Steve Bowman wrote: OK, how about moving everything into /bin except what FHS specifically says should be in /sbin? Section 3.10[0] identifies the following specifically to be located in /sbin: We can put everything in /bin and make /sbin a link to /bin. This way the utilities the FHS liste can be found in /sbin, but there physical place is elsewhere. This does not violate the standard. (The Hurd has a symlink from /usr to /, this way everything is in /bin and /sbin, this doesn't violate the FHS either). For those few remaining executables, people can make a symlink, change their PATH, create an alias, or type /sbin/ first. Of these, probably only ifconfig and route are used by many non-root users (although Joey's got a point). I think it makes sense to go the full nine miles if you start heading this direction. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 02:34:26PM +0200, Marcus Brinkmann wrote: We can put everything in /bin and make /sbin a link to /bin. This way the utilities the FHS liste can be found in /sbin, but there physical place is elsewhere. This does not violate the standard. This has nasty implications with the current implementation of dpkg, given that /sbin is currently a real directory on debian systems. -- Raul
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote: Well, the FHS is contradicting itself here. On one hand, it says that ifconfig is required to be in /sbin, on the other, according to this paragraph, since a user could ocassionally wish to run ifconfig to list the interfaces, it has to be in /bin. Someone should bring this up on the FHS list. I agree with that much. Blindly following a contradictory standard is only going to get us into trouble later on. Blindly following your fiat declarations about traceroute are getting us into trouble now. Just to rephrase my main reason for not moving traceroute, it's a tool that is in the same category as ping/ifconfig/route, i.e., it's a network diagnostic tool. On Linux, ping has traditionally been in /bin while the other three have always lived in /sbin and /usr/sbin, respectively. You can have consistency or you can have tradition. You can't have both, so cut it out. Either move ping or move traceroute. Incidentally, if one wants to argue by analogy, traceroute is more similar to ping than it is to ifconfig or route, because both traceroute and ping actually send ICMP packets out over the interface, and neither ifconfig nor route do. Under such reasoning, traceroute uncontrovertibly belongs in bin, since the FHS explicitly says ping should go in bin. Unless there is a very good reason (for the convenience of users who should really be changing their PATH variable is not good enough IMHO), we shouldn't move these things around as LOCAL scripts may depend on them. LOCAL scripts should do things the right way. I.e., not depend on the exact installed pathname of a program that should be in the $PATH. (Yes, I think unprivileged scripts wanting to call traceroute should add /usr/sbin to their $PATH. The fact that they have to do this is evidence of the breakage you have caused, not a defense for leaving things as they are.) Now if a later version of the FHS unequivocally stated that all these tools should be in /bin or /usr/bin, and as a project we decide to do that, then we can carry out such a change in a way not dissimilar to how things were moved around when the FSSTND first came about. I see. So you'll stonewall on each and every command in sbin you maintain until the FHS explicitly decrees that they move to bin. This is unacceptable, and is why I argued elsewhere for a Debian policy that removes these decisions from discretion of the package maintainer; thanks to you, we've seen that package maintainers can't be trusted with this discretion. -- G. Branden Robinson | Debian GNU/Linux| The noble soul has reverence for itself. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://www.debian.org/~branden/ | pgpJHmyE6qhZQ.pgp Description: PGP signature
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 08:34:09PM +1000, Anthony Towns wrote: This definition is really quite poor if you put too much emphasis on the ever. swapon, for example, is clearly a tool for the admin, but a user might decide one day to run it just see which version of the program is installed on the system. Well, let's not get carried away. That's a diagnostic on the tool itself and tells you nothing about the system. If all an unprivileged user of a command can do with a program is get help, the version info, its license, and similar bits of info, I don't think it qualifies for /usr. After all, such things can be (and often are) in the program's manual page, and we don't leave section 8 out of users' MANPATHs. Contrariwise, you can't read ifconfig's manpage to find out what interfaces are currently up on your system. -- G. Branden Robinson | It doesn't matter what you are doing, Debian GNU/Linux| emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://www.debian.org/~branden/ | pgp04rduXVXM6.pgp Description: PGP signature
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 10:53:51AM -0400, Raul Miller wrote: On Wed, Aug 16, 2000 at 02:42:37AM -0500, Branden Robinson wrote: I think if someone has to do such a thing, then: a) they forgot to su root; or b) they don't know they need privleges to use the command in question; or c) the command doesn't belong in sbin anyway. While I agree with your thinking, I think you've left out a case: d) they don't know about an alternative command which is already in their path. [For example: netstat -er gives the same information as route.] I don't think it's feasible for a standards body or a package maintainer to make case-by-decisions on the location of a tool based upon the functionality of every other tool that might provide that functionality. This would lead to an unstable environment, where the presence of route in bin would justified if and only if nothing else could show you the routing tables. This would also differ on a system-by-system basis as users have different packages installed. Should route go into bin for users that (somehow) don't have netstat installed, but sbin for users that do? It makes no sense. In other words, I think the choice of directory should be controlled by factors intrinsic, not extrinsic, to the program in question. -- G. Branden Robinson | One man's magic is another man's Debian GNU/Linux| engineering. Supernatural is a [EMAIL PROTECTED] | null word. http://www.debian.org/~branden/ | -- Robert Heinlein pgp2D6FPqj4VQ.pgp Description: PGP signature
Re: Intent To Split: netbase
Marcus Brinkmann ([EMAIL PROTECTED]) wrote: We can put everything in /bin and make /sbin a link to /bin. This way the utilities the FHS liste can be found in /sbin, but there physical place is elsewhere. This does not violate the standard. (The Hurd has a symlink from /usr to /, this way everything is in /bin and /sbin, this doesn't violate the FHS either). i'm no expert on capabilites, but won't their addition null the need for sbin directories? i mean, you could have a uid that can bring up interfaces, but not halt the machine. or even, halt the machine but not alter partition tables. also, i don't know how comitted debian is to using capabilites. either way, 'insmod asbestos_underware'. -- jacob kuntz [EMAIL PROTECTED] [EMAIL PROTECTED] underworld.net/~jake
Re: Intent To Split: netbase
Perhaps not. But a traceroute in /usr/bin would satisfy more people than a traceroute in /usr/sbin. Traceroute is a diagnostic command. As such it isn't general use. When a user or administrator is using it it is because of unusual conditions. My opinion is to leave it in /usr/sbin. Let them type a few extra characters, or add the sbin directories to their path. The same can be said of ping, but ping existed before the bin/sbin split. As such there is legacy code that expects it to be there. If one really wants it in the general users path, then run a symbolic link back to the original from the appropriate bin directory. -- | Bryan Andersen | [EMAIL PROTECTED] | http://softail.visi.com | | Buzzwords are like annoying little flies that deserve to be swatted. | | -Bryan Andersen|
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 12:31:47 -0500 (+), Branden Robinson wrote: On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote: Well, the FHS is contradicting itself here. On one hand, it says that ifconfig is required to be in /sbin, on the other, according to this paragraph, since a user could ocassionally wish to run ifconfig to list the interfaces, it has to be in /bin. Someone should bring this up on the FHS list. I agree with that much. [snip] What so wrong with user tools in */bin and sysadmin tools in */sbin. As an advanced user, I always put /sbin and /usr/sbin in my PATH, whatever the unix I'm on. People who know about ifconfig should know enough to add /sbin and /usr/sbin to their PATH IMO. Adrian email: [EMAIL PROTECTED] Windows NT - Unix in beta-testing. PGP key available on public key servers Debian GNU/Linux -*- because I'm allergic to Prozac -*- www.debian.org
Re: Intent To Split: netbase
On Wed, 16 Aug 2000, Anthony Towns wrote: FHS discuss people: where should traceroute go? Tradition dictates /usr/sbin, the FHS seems to indicate /usr/bin would be more appropriate. [analysis] IMHO, the deciding factor should be whether traceroute is installed setuid root. If traceroute is *not* installed setuid, then normal users cannot do anything useful with it except perhaps get usage information (which is already covered in the man page). Therefore, putting a non-setuid traceroute binary in /usr/bin is pointless; it should go in /usr/sbin because it is only useful to root. If traceroute *is* installed setuid, then implicitly, it is intended for non-root users to run. Otherwise, there would be no need to install it setuid. Therefore, if a setuid traceroute binary exists on the system, it should be in /usr/bin. I suppose one could argue that a setuid traceroute binary could be intended for non-root system accounts to run (i.e., still not be intended for all regular users), but personally, I think that would be a stretch. -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 12:40:42PM -0500, Branden Robinson wrote: In other words, I think the choice of directory should be controlled by factors intrinsic, not extrinsic, to the program in question. I think this is a reasonable viewpoint. -- Raul
Re: Intent To Split: netbase
Branden Robinson wrote: To be frank I'm not distressed by the thought of lots of programs moving from sbin to bin, or even the elimination of sbin altogether. Perhaps it would be neat to move back to what sbin was orginially used for -- static binaries. Erik Andrerson has a whole slew of them (busybox et al) that are just looking for a home. -- see shy jo
Re: Intent To Split: netbase
Manoj Srivastava wrote: Hmm. Lets step back here, and take a deep breath. What we need to consider is whether the underlying principle is desirable -- does it make sense to have two separate path components? The rationale was that for the common user, there are programs that are not used very often, and may not even work when invoked, and thus tend to only confuse the uninitiated, and annoy enerally by messing up command comletion. The question that seems to want to be raised is whether this is true? Are people really confused more by having extra commands available, or are they confused by _not_ havingcertain commands present? Sounds fine to me. The irony is, of course, that the people generally making such decisions (like this forum) are rarely a decent sampling of the user base, or the hypothetical Joe user. Maybe we should ask our users then? As to mount telling us what is mounted, so does df, and cat /etc/mtab. again, not enough to move mount; unless one is being contrary. I dont follow this. 'echo *' can tell me what files are in a directory; a system without ls in path is still broken. I don't see how mount is much different. Regular users *often* want to mount/unmount/check mount status of removable media. And it's in /bin now, so isn't this a red herring anyway? -- see shy jo
Re: Intent To Split: netbase
On 16-Aug-00, 12:31 (CDT), Branden Robinson [EMAIL PROTECTED] wrote: Blindly following your fiat declarations about traceroute are getting us into trouble now. What trouble is that? I don't consider having to type /sbin/traceroute or add /sbin to my path trouble. The constitution clearly says that maintainers have control over their packages. We have agreed that we'll follow Debian policy. Given the lack of policy on this particular topic, Herbert is perfectly within his rights to determine the location of traceroute, unless overridden by the technical committee. Since I've yet to see a truly technical reason to move it, I hope the committee won't interfere. Yes, if we were starting from scratch, it probably makes more sense to put it in bin, but it's simply not that big a deal. FWIW, I hope that policy won't take this up...detailing the /sbin - /bin location of explicit programs is bound to be an exersize in frustration. Steve
Re: Intent To Split: netbase
Branden Robinson [EMAIL PROTECTED] wrote:
Incidentally, if one wants to argue by analogy, traceroute is more similar
to ping than it is to ifconfig or route, because both traceroute and ping
actually send ICMP packets out over the interface, and neither ifconfig nor
Hmm, I didn't know that traceroute sent ICMP packets by default. Are you
sure you are talking about /usr/sbin/traceroute?
Anyway, from my personal experience,
ifconfig/route/ping/traceroute/snmpnetstat are often used together to
diagnose problems (or just waste time and bandwidth).
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 01:18:39PM -0400, Raul Miller wrote: On Wed, Aug 16, 2000 at 02:34:26PM +0200, Marcus Brinkmann wrote: We can put everything in /bin and make /sbin a link to /bin. This way the utilities the FHS liste can be found in /sbin, but there physical place is elsewhere. This does not violate the standard. This has nasty implications with the current implementation of dpkg, given that /sbin is currently a real directory on debian systems. Are you sure? I believe this bug's been fixed in the dpkg in potato. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpRP0rn32KE9.pgp Description: PGP signature
Re: Intent To Split: netbase
Branden Robinson wrote: Fine with me; either interpretation would get traceroute into (/usr)?/bin. Same here, but .. On the other hand, fsck seems to be a good example of a program that can't do much for the unprivileged user. advocate type=devil's Anyone can own a block device. /advocate -- see shy jo
Re: Intent To Split: netbase
John Goerzen ([EMAIL PROTECTED]) wrote: There is no real reason that all must listen on port 25. while i can't imagine ever justifying having postfix AND exim installed on the same machine, your argument holds true for other things. for instance, it's not uncommon to see a machine that has apache running on 80 for modperl pages, with thttpd or aolserver on 8080 for static content. not to mention what will happen when we see TUX packaged. i guess this argument will have to be decided seperatly for each service that it comes up for. personally, i think the smtpd maintainers would be waisting there time, since you can't specify a port number in an email address. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Intent To Split: netbase
Clint Adams ([EMAIL PROTECTED]) wrote: No real reason? Only one package can listen in on port 25, and Only one package can listen on port 25 of one IP. It is possible to have multiple packages listening on different ports or different IPs. hadn't thought of that. but once again, is there any benefit to that at all? will the efort required by the maintainers to get this working properly (including reading bug reports) ever balance against the tiny number of people that would use this feature? anyone that has a reason can certianly set this up themselves. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Intent To Split: netbase
On Tue, 15 Aug 2000, Jacob Kuntz wrote: while i can't imagine ever justifying having postfix AND exim installed on the same machine, your argument holds true for other things. for instance, it's not uncommon to see a machine that has apache running on 80 for I've done it - had to really.. Two reasons 1) Exim provides a different command line interface than say qmail, some software simply will not work. Thus we need a mail agent to move messages outbound only. 2) Migrating between mailers. Need to have both operational at once in order to flush queues, test and migrate. modperl pages, with thttpd or aolserver on 8080 for static content. not to mention what will happen when we see TUX packaged. Yes, good examples too. Jason
Re: Intent To Split: netbase
Branden Robinson [EMAIL PROTECTED] wrote:
On Mon, Aug 14, 2000 at 09:54:28AM -0400, Chad Miller wrote:
Hear, hear! It would be a flag day for a few poorly written programs
out there, but a reorg is worth it.
Then they're VERY poorly written. The proper way (in posix sh) to invoke a
command that should be in the path (but look before you leap) is this:
But I thought one of the main complaints was that /usr/sbin wasn't in the
PATH.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Intent To Split: netbase
On Tue, Aug 15, 2000 at 02:54:01AM -0400, Jacob Kuntz wrote: hadn't thought of that. but once again, is there any benefit to that at all? will the efort required by the maintainers to get this working properly (including reading bug reports) ever balance against the tiny number of people that would use this feature? anyone that has a reason can certianly set this up themselves. I think as long as this feature is only needed for transition we should not put much effort into it. You can just compile your own package for this transition phase and remove it later. OTOH if this is needed for a longer time it becomes a major hassle to upgrade the system because you always need to recompile the package :( cu Torsten -- Torsten Landschoff [EMAIL PROTECTED] [EMAIL PROTECTED] Debian Developer and Quality Assurance Committee Member pgpOZptuHi5FF.pgp Description: PGP signature
Re: Intent To Split: netbase
Jason == Jason Gunthorpe [EMAIL PROTECTED] writes: Jason I've done it - had to really.. Two reasons Jason1) Exim provides a different command line interface than say qmail, Jason some software simply will not work. Thus we need a mail agent to Jason move messages outbound only. Jason2) Migrating between mailers. Need to have both operational at once Jason in order to flush queues, test and migrate. I genrally have ifconfiged the machine off the network, switched, and reconnected. Unless you are talking about a _ver_ heavily uised MTA, being off line for a few minutes does not create a perceptible effect (since MTA's retry messages anyway -- often for upto 4 days, so a few minutes while installing a new one are not significant in most cases) modperl pages, with thttpd or aolserver on 8080 for static content. not to mention what will happen when we see TUX packaged. Jason Yes, good examples too. Is it really your contention that all MTA's should provide for this configurability, and cooperate with all other MTA packages out of the box? I am afraid that all this handshaking is going to entail a lot of effort, and the resultant gains seem fairly minimal ( manoj hesitantly pointing out the bit about optimizing for the overwhelmingly common case -- Where's the man could ease a heart like a satin gown? Dorothy Parker, The Satin Dress Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
On Mon, Aug 14, 2000 at 09:54:40PM -0500, Branden Robinson wrote: On the other hand, fsck seems to be a good example of a program that can't do much for the unprivileged user. That's not true. You can have disk image files you might want to check for correctness. In the Hurd, any user can boot a subhurd (a self contained system with its own critical server processes and root fs, much better than chroot) and wreck it. With fsck you can controll afterwards if the bug you traced down in the subhurd (with gdb from the parent hurd) was corrupting the filesystem. There are probably some emulators on Linux that will benefit from this as well. The distinction between sbin and bin is not a hard one. It is soft based on experience and the common case. It's also basically nonsense, because of the 2176 binaries in my path, I use a couple of dozen regularly, and having 300 further, even useless, binaries wouldn't distract me in any way. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Intent To Split: netbase
On 15 Aug 2000, Manoj Srivastava wrote: Is it really your contention that all MTA's should provide for this configurability, and cooperate with all other MTA packages out of the box? I am afraid that all this handshaking is going to entail a lot of effort, and the resultant gains seem fairly minimal ( No, it is just not common enough to be worth while. The way you do it by hand is to divert sendmail, install the alternate mailer, carefully work around the TCP service problem then hack the status file to make things sane again. It isn't undoly hard. Jason
Re: Intent To Split: netbase
On Tue, Aug 15, 2000 at 03:33:24AM -0500, Manoj Srivastava wrote: hesitantly pointing out the bit about optimizing for the overwhelmingly common case There's a difference between *optimizing* for the common case, and preventing the use of other cases without resorting to unofficial packages. -- G. Branden Robinson | Psychology is really biology. Debian GNU/Linux| Biology is really chemistry. [EMAIL PROTECTED] | Chemistry is really physics. http://www.debian.org/~branden/ | Physics is really math. pgpbK4vuzFXPG.pgp Description: PGP signature
Re: Intent To Split: netbase
On Mon, Aug 14, 2000 at 10:53:06PM -0700, Joey Hess wrote: On the other hand, fsck seems to be a good example of a program that can't do much for the unprivileged user. advocate type=devil's Anyone can own a block device. /advocate To be frank I'm not distressed by the thought of lots of programs moving from sbin to bin, or even the elimination of sbin altogether. -- G. Branden Robinson |America is at that awkward stage. It's Debian GNU/Linux|too late to work within the system, but [EMAIL PROTECTED] |too early to shoot the bastards. http://www.debian.org/~branden/ |--Claire Wolfe pgpVCCClXhxFt.pgp Description: PGP signature
Re: Intent To Split: netbase
On Tue, Aug 15, 2000 at 05:55:38PM +1000, Herbert Xu wrote: Branden Robinson [EMAIL PROTECTED] wrote: On Mon, Aug 14, 2000 at 09:54:28AM -0400, Chad Miller wrote: Hear, hear! It would be a flag day for a few poorly written programs out there, but a reorg is worth it. Then they're VERY poorly written. The proper way (in posix sh) to invoke a command that should be in the path (but look before you leap) is this: But I thought one of the main complaints was that /usr/sbin wasn't in the PATH. Generally, maintainer scripts, and programs meant to be run by root, run as root. If a program expects to use some tool that only root would use, it should expect to be running as root. -- G. Branden Robinson |America is at that awkward stage. It's Debian GNU/Linux|too late to work within the system, but [EMAIL PROTECTED] |too early to shoot the bastards. http://www.debian.org/~branden/ |--Claire Wolfe pgplrQiJV9Lmh.pgp Description: PGP signature
Re: Intent To Split: netbase
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden On Tue, Aug 15, 2000 at 03:33:24AM -0500, Manoj Srivastava wrote: hesitantly pointing out the bit about optimizing for the overwhelmingly common case Branden There's a difference between *optimizing* for the common Branden case, and preventing the use of other cases without Branden resorting to unofficial packages. Make the common things easy, and make the arcane things possible, if I may paraphrase. Sure, if one can make the arcane things easier without affecting the common things, go for it, but the law of diminishing returns applies. I still think it is reasonable for the maintainers to punt on this and let the packages conflict. As jason mentioned, it is still doable -- diversions, dpkg --force-conflict, ae /varlib/dpkg/status, and judicous use of /etc/init.d.blah --start/stop -- hard, but possible. Anyway, I am sure if people come up with a policy/patches for all the MTA's the maintainers would be happy to consider them. I am not convinced the effort is worth it, and I thus withdraw from this discussion. manoj -- Ignorance transcends architecture. James Gaskin Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
Hi, If all we are interested in hacving a miny contentous debate, please skip this message, because this pre-supposes a desire to actually compromise and come to a rough consensus. Unfortunately, common sense and a desire to actually co-operate seem to have been sorely lacking of late. Joey == Joey Hess [EMAIL PROTECTED] writes: Joey Branden Robinson wrote: On the other hand, fsck seems to be a good example of a program that can't do much for the unprivileged user. advocate type=devil's Joey Anyone can own a block device. /advocate Hmm. Lets step back here, and take a deep breath. What we need to consider is whether the underlying principle is desirable -- does it make sense to have two separate path components? The rationale was that for the common user, there are programs that are not used very often, and may not even work when invoked, and thus tend to only confuse the uninitiated, and annoy enerally by messing up command comletion. The question that seems to want to be raised is whether this is true? Are people really confused more by having extra commands available, or are they confused by _not_ havingcertain commands present? The irony is, of course, that the people generally making such decisions (like this forum) are rarely a decent sampling of the user base, or the hypothetical Joe user. If the answer is yes, there is still merit in the idea of separate path components, one needs to find a way to draw the line on where the utility lies. And we need to determine the utility for the common case -- since this is merrely a default, individual users can add to path components, create symlinks in ~/bin. or whatever, to get around the differences. I am sure that the imaginative people on this forum can come up with obscure cases where a cmmon user can generally use _any_ program out there, espescially with a judicious choice of permissions. Unless one draws the line somewhere, we shall be left with no choices for the sbin path component whatsoever. I am not so sure that is useful. To answer Joey's comment: Any one who owns a block device is probably competent enough to change their own path, and this case is definitely not enough to move fsck out of sbin. As to mount telling us what is mounted, so does df, and cat /etc/mtab. again, not enough to move mount; unless one is being contrary. manoj who'l probably just get flamed by Overfiend now -- Every Horse has an Infinite Number of Legs (proof by intimidation): Horses have an even number of legs. Behind they have two legs, and in front they have fore-legs. This makes six legs, which is certainly an odd number of legs for a horse. But the only number that is both even and odd is infinity. Therefore, horses have an infinite number of legs. Now to show this for the general case, suppose that somewhere, there is a horse that has a finite number of legs. But that is a horse of another color, and by the lemma [All horses are the same color], that does not exist. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
On Mon, Aug 14, 2000 at 10:53:06PM -0700, Joey Hess wrote: Branden Robinson wrote: Fine with me; either interpretation would get traceroute into (/usr)?/bin. Same here, but .. On the other hand, fsck seems to be a good example of a program that can't do much for the unprivileged user. advocate type=devil's Anyone can own a block device. /advocate OK, how about moving everything into /bin except what FHS specifically says should be in /sbin? Section 3.10[0] identifies the following specifically to be located in /sbin: hwclock, getty, init, update, mkswap, swapon, swapoff, fastboot, fasthalt, halt, reboot, shutdown, fdisk, fsck, fsck.*, mkfs, mkfs.*, ifconfig, and route (*=one or more of ext, ext2, minix, msdos, xia, and perhaps others) It's a concrete test, it'll satisfy what seems to be the majority opinion, and we can claim FHS compliance for it. For those few remaining executables, people can make a symlink, change their PATH, create an alias, or type /sbin/ first. Of these, probably only ifconfig and route are used by many non-root users (although Joey's got a point). [0] http://www.pathname.com/fhs/ Steve
Re: Intent To Split: netbase
Why is it considered difficult for individual users adding /sbin and /usr/sbin to their path if they wish to? I'm sure that most users are competent enough to change their own path, and if they are not, they will be soon after they find that they need to. As a user with no formal computer training, and little experience other than GNU/Linux, changing my path was among the earliest of tasks that I learned. Is there some deeper principal of Unix or Linux philosophy being discussed here? Is there something to be gained that is somehow greater than can be achieved by changing one's own path? Is there something I am missing about this debate? -- ptw miscelaneous endeavors ([EMAIL PROTECTED])
Re: Intent To Split: netbase
Steve Bowman writes: OK, how about moving everything into /bin except what FHS specifically says should be in /sbin? snip list from FHS 3.10 I very much like this idea. Does anyone have objections? -- There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
Re: Intent To Split: netbase
On 15-Aug-00, 14:35 (CDT), paul [EMAIL PROTECTED] wrote: Why is it considered difficult for individual users adding /sbin and /usr/sbin to their path if they wish to? Because stating that it is difficult is seen as an valid argument by those who wish sbin would go away. The fact that it is obviously trivial is not valid. Is there some deeper principal of Unix or Linux philosophy being discussed here? No. Is there something to be gained that is somehow greater than can be achieved by changing one's own path? No. Is there something I am missing about this debate? There are people who think that the way *they* want things set up is de-facto the way everybody want things set up. All paths, program options and defaults should be pre-configured to be exactly what they want them. Modifying configuration files, adding symlinks, or whatever is too much effort, but requiring package maintainers to greatly complicate their (the maintainers) work to accomodate every possible use of a given package is no big deal. Of course, the fact that the do it my way people don't agree about *what* the default configurations should be doesn't seem to clue them in... Steve, tired of these types of arguments.
Re: Intent To Split: netbase
Branden Robinson [EMAIL PROTECTED] wrote:
On Tue, Aug 15, 2000 at 05:55:38PM +1000, Herbert Xu wrote:
But I thought one of the main complaints was that /usr/sbin wasn't in the
PATH.
Generally, maintainer scripts, and programs meant to be run by root, run as
root.
If a program expects to use some tool that only root would use, it should
expect to be running as root.
So you do agree with me that it is better to leave traceroute in /usr/sbin?
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Intent To Split: netbase
Herbert Xu writes: Branden Robinson [EMAIL PROTECTED] wrote: Generally, maintainer scripts, and programs meant to be run by root, run as root. If a program expects to use some tool that only root would use, it should expect to be running as root. So you do agree with me that it is better to leave traceroute in /usr/sbin? Where did he say that? 'some tool that only root would use' means something that requires you to be the superuser to perform a useful action; PATH and binary locations have nothing to do with it. -- There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
Re: Intent To Split: netbase
On Tue, 15 Aug 2000 21:43:31 Manoj Srivastava wrote: The question that seems to want to be raised is whether this is true? Are people really confused more by having extra commands available, or are they confused by _not_ havingcertain commands present? I was confused by not having ifconfig in my user path. On this machine, there's only a dial-up net connection, and it has some small connectivity problems. I need to check whether the line's really up. I found myself going super-user to issue the command rather than running /sbin/ifconfig. Which is in my opinion a stupid thing to do :), but of course it felt convenient to run sudo ifconfig, and then hmmm let's see... we must come to the conclusion that there are thousands of programs with non-sense names anyway, so it would be beneficial for the user to have anything that he can run on his path. If you want people to be able to navigate in the list of available executables in a meaningful way, please author a program that does it. Bash's command completion just doesn't scale. Menu system is a good start, but not the ultimate way to find out about which programs you may run. I'd recently written in another mail to this list: --- Although ifconfig resides in /sbin, /sbin is not in the standard user path. However, many users need to run ifconfig, such as checking the IP address, or whether a dial-up link has really come up. I think it would be beneficial to supply a symbolic link to /usr/bin for this purpose. It seems that some other programs might require similar arrangements. Rationale for this proposal: Users do not need to know the location of programs that they can run, they must be able to run all the user programs that they can. A user program in this context refers to programs which are intended to be run by people, In this sense, ifconfig seems to be a user program as well as a program that can be run automatically. -- Yes, and I got a wise reply claimining that ifconfig is a system program, and a user should manually augment his path if he wishes to run it. I request you to re-consider the proposal. Supplying a symbolic link would be better than putting the /sbin in user's path, because we may then decide which programs in /sbin are needed by normal users. Thanks, __ Eray Ozkural
Re: Intent To Split: netbase
On Wed, Aug 16, 2000 at 01:12:58AM +0300, Eray Ozkural wrote: I was confused by not having ifconfig in my user path. On this machine, there's only a dial-up net connection, and it has some small connectivity problems. I need to check whether the line's really up. I found myself going super-user to issue the command rather than running /sbin/ifconfig. ifconfig is a required file for /sbin according the the FHS section 3.10 as distributed in the debian-policy package. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgps6l6WNTk15.pgp Description: PGP signature
Re: Intent To Split: netbase
Andreas Fuchs [EMAIL PROTECTED] writes: Good enough for you? Good enough for anyone? ajt? (-: Bad idea. Then you also want every X11-app to ask if it should install itself in /usr/X386/bin or somewhere else and every game-like app if it should instaal it self in /usr/bin or /usr/games? Either agree on placing the different programs one place og agree to disagree. I have had /sbin and /usr/sbin in my PATH for years neither my sysadm or me have any problems with that. -- Peter
Re: Intent To Split: netbase
Herbert Xu [EMAIL PROTECTED] writes: Please also note that other daemons conflict with each other well, e.g., inn cnews, sendmail postfix. I am aware of that, and it's a shame, there is no real reason that they cannot coexist.
Re: Intent To Split: netbase
Andreas Fuchs writes: Hm. So why not make it the admin's choice? How about' snip Setting up netbase (version) ... In the standard configuration, some binaries of netbase are installed in /usr/sbin, which is, by default, not included in the user's search paths. Do you want to create a symbolic link for each program below from /usr/bin to /usr/sbin, thus putting them in a regular user's search path: Oh, this is just absurd. I see no reason why we should subject users to filesystem-layout politics. Move it or don't move it. -- There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
Re: Intent To Split: netbase
Hi, John == John Goerzen [EMAIL PROTECTED] writes: John Herbert Xu [EMAIL PROTECTED] writes: Please also note that other daemons conflict with each other well, e.g., inn cnews, sendmail postfix. John I am aware of that, and it's a shame, there is no real reason that John they cannot coexist. No real reason? Only one package can listen in on port 25, and only one package may be linked to /usr/lib/sendmail. Now the latter may be handled by using diversions/alternatives, but I fail to see how the former can be handled. (similar arguments for NNTP servers) Seems like there are *real* reasons. There may be partial work arounds, but the conflict does seem reasonable. manoj -- It pays in England to be a revolutionary and a bible-smacker most of one's life and then come round. Lord Alfred Douglas Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
On Monday, 14 August 2000 at 14:20, Manoj Srivastava wrote: Hi, John == John Goerzen [EMAIL PROTECTED] writes: John Herbert Xu [EMAIL PROTECTED] writes: Please also note that other daemons conflict with each other well, e.g., inn cnews, sendmail postfix. John I am aware of that, and it's a shame, there is no real reason that John they cannot coexist. No real reason? Only one package can listen in on port 25, and only one package may be linked to /usr/lib/sendmail. Now the latter may be handled by using diversions/alternatives, but I fail to see how the former can be handled. (similar arguments for NNTP servers) Seems like there are *real* reasons. There may be partial work arounds, but the conflict does seem reasonable. I agree with you in general. But it would be nice if packages that conflicted on, say, portnumber, could let you choose another port to run them on, and maybe give the official port to one particular program (like alternatives for portnumbers). I realise quite a lot of programs have hardcoded portnumbers in the upstream source, and that for most purposes it wouldn't often be super useful, but it does have certain advantages. For instance, on my machine I have uw-imap, cyrus-imap and courier-imap all installed on different ports so I can test out my IMAP client code against the three of them. Since they all conflict I have to install and maintain at least two of them by hand... well, that's the motivation behind my stupid wishlist :) -- Don't make Godzilla mad! pgpzmZpHoxQwx.pgp Description: PGP signature
Re: Intent To Split: netbase
Manoj Srivastava [EMAIL PROTECTED] writes: John Herbert Xu [EMAIL PROTECTED] writes: Please also note that other daemons conflict with each other well, e.g., inn cnews, sendmail postfix. John I am aware of that, and it's a shame, there is no real reason that John they cannot coexist. No real reason? Only one package can listen in on port 25, and There is no real reason that all must listen on port 25. only one package may be linked to /usr/lib/sendmail. Now the latter Obviously. That doesn't mean that there still can't be multiple servers on a machine. may be handled by using diversions/alternatives, but I fail to see how the former can be handled. (similar arguments for NNTP servers) Seems like there are *real* reasons. There may be partial work arounds, but the conflict does seem reasonable. These aren't real reasons at all. There is nothing to prevent a mail server from working on a different port. manoj -- It pays in England to be a revolutionary and a bible-smacker most of one's life and then come round. Lord Alfred Douglas Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- John Goerzen [EMAIL PROTECTED] www.complete.org Sr. Software Developer, Progeny Linux Systems, Inc.www.progenylinux.com #include std_disclaimer.h [EMAIL PROTECTED]
Re: Intent To Split: netbase
On Thu, Aug 10, 2000 at 03:22:43PM +1000, Anthony Towns wrote: On Thu, Aug 10, 2000 at 12:47:34AM -0400, Decklin Foster wrote: Anthony Towns writes: Well, if you wanted half the people running unstable to just blithely upgrade and have all their firewalling disappear, you could remove the dependencies, I guess. The argument for getting rid of all the stuff still lying around in netbase is that once the package really is a dummy ``this-only-exists- so-that-people-can-upgrade-easily'' package, then it can be removed, getting rid of the dependency on what the user doesn't want to install. Right now we can't do that, which I what I think Alex's point was. No. The point of splitting netbase isn't in particular to do away with the package. Just because that's what happened to netstd and xbase doesn't necessarily mean it'll happen again. I've no plans to make netbase not exist anymore. I do hope that you'll consider changing some of the Depends: to Suggests:. For example, I don't generally want portmap to be installed on servers I deploy. Peace, * Kurt Starsinic ([EMAIL PROTECTED]) -- Senior Network Engineer * |`The future masters of technology will have to be lighthearted and | | intelligent. The machine easily masters the grim and the dumb.' | |-- Marshall McLuhan|
Re: Intent To Split: netbase
No real reason? Only one package can listen in on port 25, and Only one package can listen on port 25 of one IP. It is possible to have multiple packages listening on different ports or different IPs.
Re: Intent To Split: netbase
John == John Goerzen [EMAIL PROTECTED] writes: No real reason? Only one package can listen in on port 25, and John There is no real reason that all must listen on port 25. Then you and I have very different opinions on what a working MTA is. Indeed, the SMTP RFC's differ with your opinion as well John These aren't real reasons at all. Given that, you have a curious definition of ``real''. Unfortunately, I do not think I find your definition of real very interesting. Brendan I agree with you in general. But it would be nice if Brendan packages that conflicted on, say, portnumber, could let you Brendan choose another port to run them on, and maybe give the Brendan official port to one particular program (like alternatives Brendan for portnumbers). I realise quite a lot of programs have Brendan hardcoded portnumbers in the upstream source, and that for Brendan most purposes it wouldn't often be super useful, but it does Brendan have certain advantages. One should optimize for the most common case. I think people who can maneuver around the port numbers can also recompile or use dpkg -x effectively. I am unsure that the results are quite worth the effort that needs be expended. manoj -- Support your local church or synagogue. Worship at Bank of America. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Intent To Split: netbase
On Mon, Aug 14, 2000 at 10:27:22AM -0500, Manoj Srivastava wrote: Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden Of course. The obvious answer is that programs that have Branden some utility to unprivileged users should go in /bin (or Branden /usr/bin). The problem with that is that it is all so very subjective, and it all depends on the ``unprivileged user''. Under this tacit policy, there is unlikely to be a solution that satisfies anyone. Indeed, a more workable criteria may be to put things in sbin that _require_ priviledges (things like mount, fsck, etc), and say that sbin contains programs that are useless to the unpriviledged user. I think that would be way less controversial. Fine with me; either interpretation would get traceroute into (/usr)?/bin. Actually, I disagree with your example of mount. It's quite handy even without privileges. It tells me what's mounted. Same with ifconfig, it tells you what interfaces are up and doesn't need privileges to do so. On the other hand, fsck seems to be a good example of a program that can't do much for the unprivileged user. -- G. Branden Robinson |Kissing girls is a goodness. It is a Debian GNU/Linux|growing closer. It beats the hell out [EMAIL PROTECTED] |of card games. http://www.debian.org/~branden/ |-- Robert Heinlein pgp5QLw4PtsGQ.pgp Description: PGP signature
Re: Intent To Split: netbase
On Mon, Aug 14, 2000 at 09:54:28AM -0400, Chad Miller wrote: On Mon, Aug 14, 2000 at 09:22:27AM -0400, Michael Stone wrote: Perhaps not. But a traceroute in /usr/bin would satisfy more people than a traceroute in /usr/sbin. Hear, hear! It would be a flag day for a few poorly written programs out there, but a reorg is worth it. Then they're VERY poorly written. The proper way (in posix sh) to invoke a command that should be in the path (but look before you leap) is this: if command -v desired_command /dev/null 21; then desired_command --args fi (It would be nice if POSIX had thought to include a -s option to shut command up and just return an exist status so as to avoid all that ugly redirection, but oh well.) -- G. Branden Robinson | If you have the slightest bit of Debian GNU/Linux| intellectual integrity you cannot [EMAIL PROTECTED] | support the government. http://www.debian.org/~branden/ | -- anonymous pgp1okw0A1JpG.pgp Description: PGP signature
Re: Intent To Split: netbase
Branden Of course. The obvious answer is that programs that have Branden some utility to unprivileged users should go in /bin (or Branden /usr/bin). The problem with that is that it is all so very subjective, and it all depends on the ``unprivileged user''. Under this tacit policy, there is unlikely to be a solution that satisfies anyone. Indeed, a more workable criteria may be to put things in sbin that _require_ priviledges (things like mount, fsck, etc), and say that sbin contains programs that are useless to the unpriviledged user. I think that would be way less controversial. Traceroute is not controversial. See... even licq comes configured by default to call traceroute on other connected users. Traceroute is like finger, it explores how another host is connected, it's like whois. It's a site wide networking tool, like rwho or rwall. It has friendly user interfaces, like mtr or xt. All these programs are in /usr/bin.
Re: Intent To Split: netbase
Then you also want every X11-app to ask if it should install itself in /usr/X386/bin or somewhere else and every game-like app if it should instaal it self in /usr/bin or /usr/games? Worse: There's a package which asks the sysadmin where is dpkg in the sustem..!
