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
> 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 ma
>>"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
ect: 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
>
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
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
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 -- vers
>>"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 s
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 mkis
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. Y
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 m
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 examp
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. Anyon
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
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 does
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
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 s
>>"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
appl
>>"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?
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 inse
>>"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
>>"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 hav
>>"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.)
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
>>"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 witho
[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 listeni
[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
> >
[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
>>"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.
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 p
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
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/
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
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
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,
> rout
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
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 /
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
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
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 th
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 clearl
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 no
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
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
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 tracerout
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, si
> 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
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
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;
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 installe
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
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 wi
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
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
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 s
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.
>
>
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
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
[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
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 ne
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 scr
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?
>
>
> I very much like this idea. Does anyone have objections?
I don't object. I still think a few of
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,
/us
>>"Anthony" == Anthony Towns 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>
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-
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 havin
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
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 e
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
Steve Bowman writes:
> OK, how about moving everything into /bin except what FHS specifically
> says should be in /sbin?
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 proba
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 tra
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 unprivileg
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
>>"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
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.
>
> > Th
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.
>
>
> Anyone can own a block device.
>
To be frank I'm not distressed by the thought of lots of programs moving
from s
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
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
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 boo
>>"Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
Jason> I've done it - had to really.. Two reasons
Jason>1) 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 outb
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
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
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..
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,
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 ap
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.
Anyone can own a block device.
--
see shy jo
> 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..!
> 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 tac
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
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).
>
>
>>"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 wit
> 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.
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
>
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>
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.
>
>
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
Andreas Fuchs writes:
> Hm. So why not make it the admin's choice? How about'
>
>
> 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
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.
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?
Eit
99 matches
Mail list logo
