Re: poor documentation example

[Bruce Guenter]

On Sat, Mar 27, 1999 at 10:25:02PM -0800, Russ Allbery wrote:
> Dan, would you consider providing some way for the installation location
> to be different than the final run location?

The method I have used (successfully) is to set up conf-home for the run
location, do a make, and then set conf-home for the install location and
run "make install".  It will only rebuild those files needed for the
install binary without touching the others.
-- 
Bruce Guenter, QCC Communications Corp.  EMail: [EMAIL PROTECTED]
Phone: (306)249-0220   WWW: http://www.qcc.sk.ca/~bguenter/

Re: poor documentation example

[Jay Soffian]

 "Mark" == Mark Delany <[EMAIL PROTECTED]> writes:

>> But I'm sure djb knows his way is better, so this is all a
>> waste of breath now, isn't it.

Mark> So lemme get this right. Dan B. has written and made freely
Mark> available an MTA that many people like. Russell N. has set
Mark> up a web site to help distribute information about that
Mark> MTA. Numerous others are running mirrors for the web site
Mark> and ftp archives all over the planet. Plenty of people have
Mark> made patches and alternative distributions freely
Mark> available. Even more people have provided thousands of hours
Mark> of free support on this list and Dave S. is running a free
Mark> web site that archives this list for future prosperity.

I don't think that's fair. I didn't criticize the contributions of any
of those people.

For what it's worth: Thank you all who help to make the Internet a
better place. That includes everyone Mark mentioned.

Mark> And the best you have to offer is what? A sarcastic tirade?

A tirade? Please. It was one sarcastic remark. I'm glad that Dan has
written the software he has. We rely on it daily. And Dan can do
whatever the heck he wants with his software. But everyone on this
list knows how difficult it can be to convince Dan that there might be
a better way. It's a little frustrating sometimes. Thus my remark. In
any case, it was inappropriate, so I apologize.

Dan often laments about how fractured the Unix world is. Yet his
installation method is yet another non-standard installation method I
have to deal with. His software is easy to build and install as long
as it conforms to his ideas about how software should be built and
installed. I'm willing to live with /var/qmail. I am not willing to
live with stuffing everything under /usr/local.

j.
--
Jay Soffian <[EMAIL PROTECTED]>   UNIX Systems Administrator
404.572.1941 Cox Interactive Media

Re: poor documentation example

[Scott D. Yelich]

On 27 Mar 1999, Russ Allbery wrote:
> Jay Soffian <[EMAIL PROTECTED]> writes:
> >  "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
> > Russ> make 
> > Russ> make install
> > Russ> ./install /depot/col//bin < BIN
> > Russ> ./install /depot/col//man < MAN
> > For what is that supposed to work? It doesn't work for ucspi-tcp-0.84.
> 0.80.  *grumble*  You're right, he changed the way install works.  It used
> to take input files BIN and MAN.  Now it actually compiles the package
> locations into everything.  How annoying.

*rofl*  I went and looked and said ``Gee, that's kinda nifty --
even if it's not documented anywhere'' ... but, alas, I couldn't
find heads or tails of that.  I figured I was just *missing*
it again... and didn't say anything.

I talked to another admin tonight who just installed
qmail-popup.  He complained that the install documentation
was pathetic.  Hey, I'm just passing along what I hear.

> Dan, would you consider providing some way for the installation location
> to be different than the final run location?  Those of us who use AFS with
> a reasonably large software installation *require* that; it's not possible
> for us to install into the same location that users will run the binaries
> from.

Just document it... whatever it is.  Please.

Scott

Re: poor documentation example

[Russ Allbery]

Jay Soffian <[EMAIL PROTECTED]> writes:
>  "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:

> Russ> make 
> Russ> make install
> Russ> ./install /depot/col//bin < BIN
> Russ> ./install /depot/col//man < MAN

> For what is that supposed to work? It doesn't work for ucspi-tcp-0.84.

0.80.  *grumble*  You're right, he changed the way install works.  It used
to take input files BIN and MAN.  Now it actually compiles the package
locations into everything.  How annoying.

Dan, would you consider providing some way for the installation location
to be different than the final run location?  Those of us who use AFS with
a reasonably large software installation *require* that; it's not possible
for us to install into the same location that users will run the binaries
from.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>

Re: poor documentation example

[Vince Vielhaber]

On 28-Mar-99 Jay Soffian wrote:
>  "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
> 
> Russ> make 
> Russ> make install
> Russ> ./install /depot/col//bin < BIN
> Russ> ./install /depot/col//man < MAN
> 
> For what is that supposed to work? It doesn't work for ucspi-tcp-0.84.

# make
# make setup check


Vince.
-- 
==
Vince Vielhaber -- KA8CSH   email: [EMAIL PROTECTED]   flame-mail: /dev/null
   # includeTEAM-OS2
Online Campground Directoryhttp://www.camping-usa.com
   Online Giftshop Superstorehttp://www.cloudninegifts.com
==

Re: poor documentation example

[Jay Soffian]

 "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:

Russ> make 
Russ> make install
Russ> ./install /depot/col//bin < BIN
Russ> ./install /depot/col//man < MAN

For what is that supposed to work? It doesn't work for ucspi-tcp-0.84.

j.
--
Jay Soffian <[EMAIL PROTECTED]>   UNIX Systems Administrator
404.572.1941 Cox Interactive Media

Re: poor documentation example

[Russ Allbery]

Jay Soffian <[EMAIL PROTECTED]> writes:

> Also, none of djb's packages like the idea of compiling a program to
> look in one place and installing it in another. We use depot for all our
> package installes, so we compile packages to look in /usr/local, but
> install them in /depot/col/. All of djb's packages require
> extra work to get them to install this way. For qmail, it isn't that big
> a deal because we put it in /var/qmail, but for tcpserver and other djb
> packages, we want them depotized. For pacakges that use GNU autoconf,
> this is trivial. 'make install prefix=/depot/col/' and
> you're done. For all of djb's stuff, you either install by hand or futz
> around with the various conf-FOO files and make sure you preserve their
> timestamps when editing them after you've built the package. blech.

make
make install
./install /depot/col//bin < BIN
./install /depot/col//man < MAN

If that's too much to type each time, make a local patch to Makefile that
gets the installatin locations from conf-instbin and conf-instman instead
and creates those files with the installation paths you want.

(Your package manager *does* seamlessly allow you to keep local patches to
a package, right?)

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>

Re: poor documentation example

[Russell Nelson]

Mark Delany writes:
 > Even more people have provided thousands of hours of free support
 > on this list

Your modesty becomes you.  Mark D. is one of the people who provides
that support, and an excellent job you do, too.

-- 
-russ nelson <[EMAIL PROTECTED]>  http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok |   There is good evidence
521 Pleasant Valley Rd. | +1 315 268 1925 voice |   that freedom is the
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   |   cause of world peace.

Re: poor documentation example

[Mark Delany]

>But I'm sure djb knows his way is better, so this is all a waste of
>breath now, isn't it.

So lemme get this right. Dan B. has written and made freely available an MTA 
that many people like. Russell N. has set up a web site to help distribute 
information about that MTA. Numerous others are running mirrors for the web 
site and ftp archives all over the planet. Plenty of people have made 
patches and alternative distributions freely available. Even more people 
have provided thousands of hours of free support on this list and Dave S. is 
running a free web site that archives this list for future prosperity.

And the best you have to offer is what? A sarcastic tirade?

A truly stunning contribution.


Regards.

Re: poor documentation example

[Jay Soffian]

 "Scott" == Scott D Yelich <[EMAIL PROTECTED]> writes:

>> I've had tcpserver compile just fine even with HP's broken
>> compiler.  It seems as if you're trying to find fault just to
>> try and prove your point.  If you know/knew in advance of your
>> non-standard compiler setup you'd be prepared for it.

Scott> *sigh*

Scott> You just don't get it... do you.

Scott> I have a standard compiler set up.  I have gcc.  I do not
Scott> have cc.

Scott> I get 99% of my programs in source and they tell me to edit
Scott> the Make file and change the "cc" line to "gcc" or to type
Scott> ./Configure.  Both of these get me to compile (maybe I have
Scott> to define solaris, etc.) just fine.

Scott> Then comes qmail, et al., does it use Makefile with CC=gcc?
Scott> no.  Does it use ./Configure? no.  It says "type make; make
Scott> config check; # that's all!"

Scott> BUT IT IS NOT ALL.

Scott> That's all (I'm trying to say).


Well, at least I agree with this. tcpserver is the ONLY package (well,
not including other djb packages which have this same breakage) I have
ever compiled where not even this works:

make CC=gcc

Also, none of djb's packages like the idea of compiling a program to
look in one place and installing it in another. We use depot for all
our package installes, so we compile packages to look in /usr/local,
but install them in /depot/col/. All of djb's packages
require extra work to get them to install this way. For qmail, it
isn't that big a deal because we put it in /var/qmail, but for
tcpserver and other djb packages, we want them depotized. For pacakges
that use GNU autoconf, this is trivial. 'make install
prefix=/depot/col/' and you're done. For all of djb's
stuff, you either install by hand or futz around with the various
conf-FOO files and make sure you preserve their timestamps when
editing them after you've built the package. blech.

But I'm sure djb knows his way is better, so this is all a waste of
breath now, isn't it.

j.
--
Jay Soffian <[EMAIL PROTECTED]>   UNIX Systems Administrator
404.572.1941 Cox Interactive Media

Re: poor documentation example

[Sam]

Cris Daniluk writes:

> I've adminned Solaris for years and I definitely don't have cc linked to gcc.
> It causes headaches often, but I typically grep cc * ahead of time if no
> autoconf is present... quickly replacing cc with gcc solves things but I must
> agree with you, this is NOT the users responsibility to omnisciently know this.

I must've been out of town when the job of installing a mail server has
been delegated to users.  In the old days, it were the admins who did these
kinds of things.

You can argue that documentation for things that users run should be dumbed
down.  rblsmtpd should not be installed by users.


-- 
Sam

Re: poor documentation example

[Cris Daniluk]

"Scott D. Yelich" wrote:

> On 23 Mar 1999, Russ Allbery wrote:
> > Sam <[EMAIL PROTECTED]> writes:
> > > "Standard Solaris machine" is not the same thing as a "Standard UNIX
> > > machine".  A standard UNIX machine comes with a functioning C compiler.
> > Solaris doesn't.  HP-UX comes with something that's functioning only under
> > the most general possible definition of the term.  I don't believe AIX
> > does.  IRIX doesn't even come with header files, let alone a compiler.
> > Linux and *BSD come with functioning C compilers.
>
> This may not be the place to ask... and I'm not sure I'd like
> the answers -- but I'll ask anyway:
>
> (1) is it standard (practice) to link cc to gcc? (and who says it is
> standard practice?)
> and
> (2) how many people here have done this?
>
> As far as linking cc to gcc breaking things.  I'll provide examples.
> Say, was the SunOS cc ansi compatible?  I really do remember
> commany line options to cc that didn't work with gcc and
> vice-versa.
>
> Scott

It is "standard" practice to link cc to your DEFAULT compiler, not always gcc.
However, it often *isn't* done because many people assume cc is always gcc and
pass options to it that shouldn't be passed to it. For example, many egcs
command options are different, like you mentioned with SunOS cc.

I've adminned Solaris for years and I definitely don't have cc linked to gcc.
It causes headaches often, but I typically grep cc * ahead of time if no
autoconf is present... quickly replacing cc with gcc solves things but I must
agree with you, this is NOT the users responsibility to omnisciently know this.
It unquestionably sucks that things are the way they are, but whether you like
it or not, it is how it is. It's stupid. Yup. Can't change that. That's why
documentation is supposed to be detailed and cover things like this. There has
been a lot of stupid clout on this thread, but I think when you get back to
what started it all, it is very legitimate. The documentation might be best to
tell you to configure conf* to suit your needs and leave it at that. Only one
line, noone dies, and Scott's problem is solved...


--
Cris Daniluk   [EMAIL PROTECTED]
-
Digital Services Network, Inc.   http://www.dsnet.net
1129 Niles-Cortland Road, Warren, Ohio 44484  [EMAIL PROTECTED]
(330) 609-8624 ext. 20 Fax (330) 609-9990
 The Web Hosting Specialists
-

Re: poor documentation example

[craig]

>Which might result in my dumbing it down too much, but that's another problem.

It's a risk worth taking.  Think of the audience as reading at the
level of 5th-graders or so.  That doesn't necessarily mean dumbing
it down.  It does mean picking and using consistent terms for things,
writing clearly and concisely, and so on.

The audience for technical documentation, no matter *how* intellectually
advanced, includes very few people who actually *read* it at their
"advanced" level.  The vast majority of readers instead dabble in it,
here and there, while focusing most of their (pertinent) mental activity
on *other* things, like the various jobs they're actually trying to
accomplish (which often only tangentially require figuring out how to
use some piece of software).

Avoiding dumbing it down is important, though, because advanced readers
might accidentally misinterpret dumbed-down writing.  If you can't
see a way to bring up an important option, or facility, early on, while
keeping things clear, go ahead and *say* that, for example -- a footnote
or a parenthetical paragraph can let advanced readers know that, indeed,
Greater Things are afoot, without unduly confusing those who are
just begining to grapple with the topics presented.

I miss the days of my youth, when I actually had the time *and* the
inclination to read entire manuals on software over and over again,
until I'd nearly committed them to memory.  That may be the best way to
learn about new products today.  It probably is the best way to learn
about qmail, given the sort of documentation it has (which probably
has a very high "truth ratio", but certainly has much lower quality
as technical documentation than the software itself -- which doesn't
actually say much that's bad about the documentation).

But, the best way to *write* about new products today is to understand
that many readers will look at, say, a section, or even screenful,
of documentation every couple of days, and occasionally look up terms
in the index (following only one or two of the references), *at most*
during their initial attempts to use the product.

Such readers are best served by simplified roadmaps, which in turn
are backed up by clear, direct, and consistent chunks of documentation.

tq vm, (burley)

Re: poor documentation example

[Russ Allbery]

[EMAIL PROTECTED] writes:

> No need to edit the Makefile to set the compiler option. As a feature of
> make you can pass the necessary parameters from the command line like
> so:- 'make CC=gcc' or whatever compiler is necessary. At no stage is it
> absolutely necessary to edit the make file.

Have you tried to do this with Dan's software?  I don't believe it works
with his compile script.  He doesn't use make to generate the compilation
lines.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>

Re: poor documentation example

[Vince Vielhaber]

On 24-Mar-99 Cris Daniluk wrote:
> Racer X wrote:
> 
>> > Why not mention *this* in this INSTALL?
>> >
>> > How many people here had to ask or figure this out for
>> > themselves provided that they didn't have "cc" working?
>>
>> Uh, you're kidding, right?
>>
>> I think the assumption is that you won't be messing around with compiling a
>> new mail server (or anything else for that matter) from scratch if you
>> can't even figure out your compiler.  I've yet to find a stock system with
>> development tools installed where "cc" didn't invoke the compiler.
>>
>> shag
> 
> Solaris? QNX? HPUX? AIX?

HPUX comes with a crippled compiler.  Has since at least v6 and I have 
compiled qmail with it.

Vince.
-- 
==
Vince Vielhaber -- KA8CSH   email: [EMAIL PROTECTED]   flame-mail: /dev/null
   # includeTEAM-OS2
Online Campground Directoryhttp://www.camping-usa.com
   Online Giftshop Superstorehttp://www.cloudninegifts.com
==

Re: poor documentation example

[Fabrice Scemama]

"Scott D. Yelich" wrote:
> This may not be the place to ask... and I'm not sure I'd like
> the answers -- but I'll ask anyway:
> 
> (1) is it standard (practice) to link cc to gcc? (and who says it is
> standard practice?)
> and
> (2) how many people here have done this?
> 
> As far as linking cc to gcc breaking things.  I'll provide examples.
> Say, was the SunOS cc ansi compatible?  I really do remember
> commany line options to cc that didn't work with gcc and
> vice-versa.
> 
> Scott

Any Linux distribution has cc linked to gcc.

Concerning AIX: i sometimes use an AIX 3.2.5 old box, where
cc was present. This compiler is still doing a good job
(i've used it to compile perl 5.00502 for example). This box
was installed in '93.

Fabrice

Re: poor documentation example

[Racer X]

> > Uh, you're kidding, right?
> >
> > I think the assumption is that you won't be messing around with
compiling a
> > new mail server (or anything else for that matter) from scratch if you
> > can't even figure out your compiler.  I've yet to find a stock system
with
> > development tools installed where "cc" didn't invoke the compiler.
> >
> > shag
>
> Solaris? QNX? HPUX? AIX?

Thank you Cris, for illustrating one of the prime shortcomings of all
documentation ever printed - it can't force anyone to read, just as I can't
force you to read my message before you typed out a reply.

Should I have put "with development tools installed" in all caps?

I'm personally rather tired of this thread, as it seems to be mainly
between a) people who are too lazy to do a little research but evidently
have lots of energy to bitch, and b) people who have no sympathy for those
people in group "a."  I apologize for continuing the thread but I felt this
message might illustrate to group "a" exactly WHY they get no sympathy.

shag

Re: poor documentation example

[Cris Daniluk]

Racer X wrote:

> > Why not mention *this* in this INSTALL?
> >
> > How many people here had to ask or figure this out for
> > themselves provided that they didn't have "cc" working?
>
> Uh, you're kidding, right?
>
> I think the assumption is that you won't be messing around with compiling a
> new mail server (or anything else for that matter) from scratch if you
> can't even figure out your compiler.  I've yet to find a stock system with
> development tools installed where "cc" didn't invoke the compiler.
>
> shag

Solaris? QNX? HPUX? AIX?

--
Cris Daniluk   [EMAIL PROTECTED]
-
Digital Services Network, Inc.   http://www.dsnet.net
1129 Niles-Cortland Road, Warren, Ohio 44484  [EMAIL PROTECTED]
(330) 609-8624 ext. 20 Fax (330) 609-9990
 The Web Hosting Specialists
-

Re: poor documentation example

[Mark E Drummond]

"Scott D. Yelich" wrote:
> 
> How many people here had to ask or figure this out for
> themselves provided that they didn't have "cc" working?

I did. It was a quite fix but it was one which could have been avoided.
That's what autoconf & automake are for.

-- 
_
Mark E Drummond  Royal Military College of Canada
[EMAIL PROTECTED]  Computing Services
Linux Uber Alles  perl || die

Re: poor documentation example

[Kai MacTane]

Text written by Scott D. Yelich at 07:02 PM 3/23/99 -0700:
>
>Regarding the wrapper -- yes, the wrapper is a decent idea.  Then
>everyone would have to be educated (ie: forced?) to use that command and
>not an alternative such as npasswd, etc.  Of course, the only way to
>do this would probably be to disable the old passwd (and wonder
>what that breaks).  It's not all that simple, in the end.

I'm not familiar with npasswd and other alternatives. My solution would
have involved renaming passwd to something else (perhaps "passwd.orig"),
naming my wrapper "passwd", and simply having it validate arguments before
passing them on to passwd.orig.

I agree it's not that simple, but it's not necessarily that complex, either.

>Right.  I prefer the idea of having decent documentation on things so
>that I don't have to read the author's mind.

I agree. I'm in the process of writing a few (very small) open-source
projects right now, and I'm keeping some of the things I've seen on this
list in the back of my mind as I write the docs.

I've also got a wonderful real-world case to observe: we've got a new
sysadmin here where I work, and after two or three months here, he's still
going "Where in the docs did you find that?" (For example, just yesterday,
we got spammed by someone in China, so I dropped their IP numbers into a
few tcpserver deny rules. Then I had to show him where in the docs to find
the info on that.) And this guy is not a newbie or a luser; he's an
experienced Unix/Linux sysadmin. He is, however, a Qmail newbie, and seeing
his reaction to the docs is causing me to want to make *really sure* that
my own documentation doesn't do that to people.

Which might result in my dumbing it down too much, but that's another problem.

-
 Kai MacTane
 System Administrator
  Online Partners.com, Inc.
-
>From the Jargon File: (v4.0.0, 25 Jul 1996)

fix /n.,v./ 

What one does when a problem has been reported too many times to 
be ignored. 

Re: poor documentation example

[Vince Vielhaber]

On Wed, 24 Mar 1999, Julian L.C. Brown wrote:

> 
> >That's all (I'm trying to say).  
> 
> Whatever it is you are trying to say, take it to private message.  I read
> the qmail list for qmail oriented messages not nonsense.
> 
> Julian
> 
> 

No need to copy me, Julian, I'm on the list.

Vince.
-- 
==
Vince Vielhaber -- KA8CSH   email: [EMAIL PROTECTED]   flame-mail: /dev/null
   # includeTEAM-OS2
Online Campground Directoryhttp://www.camping-usa.com
   Online Giftshop Superstorehttp://www.cloudninegifts.com
==

Re: poor documentation example

[craig]

>People miss my humor so much I sometimes think I'm not funny.

There might be a clue in there somewhere.  :)

tq vm, (burley)

P.S. I'm at least half-kidding, as I often run into the same sort of thing.

Re: poor documentation example

[Julian L.C. Brown]

>That's all (I'm trying to say).  

Whatever it is you are trying to say, take it to private message.  I read
the qmail list for qmail oriented messages not nonsense.

Julian

Re: poor documentation example

[mgibbins]

On Tue, 23 Mar 1999, Scott D. Yelich wrote:

> 
> Then comes qmail, et al., does it use Makefile with
> CC=gcc? no.  Does it use ./Configure? no.  It says
> "type make; make config check; # that's all!"
> 
No need to edit the Makefile to set the compiler option. As a
feature of make you can pass the necessary parameters from the command
line like so:- 'make CC=gcc' or whatever compiler is necessary. At no
stage is it absolutely necessary to edit the make file.


-- 
Our OS who art in CPU, UNIX be thy name.
Thy programs run, thy syscalls done,
In kernel as it is in user!
*
Matthew Gibbins
email : [EMAIL PROTECTED]

Re: poor documentation example

[Matt Simerson]

On Tue, 23 Mar 1999, Scott D. Yelich wrote:

> So, this client owns their own isp.  They have root access.  They often
> type "passwd" without an account to change the password for one of
> their account -- yet they zap the root password.  Ignore my solution --
> how would you prevent this provided that the isp owner will not stop
> using the command and you don't want to write a wrapper for them around
> the root command (since it's not a single person who does this).

Easy enough, use something like sudo and adjust your passwd program (you
have source right?) to disallow the changing of the root password. Only
allow them to execute your passwd changing 
through sudo. You're the consultant. It's your job to protect them
from themselves. :-)

Matt

``
  Matt Simersonhttp://users.michweb.net/~matt
  MichWeb Inc. - President http://www.michweb.net   
  The Art Farm - Technical Wizard  http://www.theartfarm.com
  
  Better to dare Mighty Things and fail, than to live in __o
a gray twilight where there is neither victory or  _-\<,_
defeat. -- attributed to Theodore Roosevelt ..(_)/ (_)
``

Re: poor documentation example

[Scott D. Yelich]

Regarding the wrapper -- yes, the wrapper is a decent idea.  Then
everyone would have to be educated (ie: forced?) to use that command and
not an alternative such as npasswd, etc.  Of course, the only way to
do this would probably be to disable the old passwd (and wonder
what that breaks).  It's not all that simple, in the end.

> >Ok, so it was a poor choice of words.  I thought it was clever.
> Sorry, it went straight over my head. After all, "root" does have another
> common meaning in Unix-ese.

What does it mean to Australians? Wouldn't it be nice to change your
fv >My safeguard is another copy of the original root password in the
> >/etc/password (or /etc/shadow) file.  I really didn't see it
> >as a major foopah.
> I don't think it's really that awful, although I do prefer the idea of
> training the users to deal with the system properly rather than expecting
> it to read their minds.

Right.  I prefer the idea of having decent documentation on things so
that I don't have to read the author's mind.

Do I have to install tcpserver as root?  I did and I didn't even
check beforehand.  I *trust* djb.  It doesn't mean that a config
wasn't missed that would do something that I'd really prefer not
be done to my system, though.

Scott

Re: poor documentation example

[Kai MacTane]

Text written by Scott D. Yelich at 06:46 PM 3/23/99 -0700:
>
>> >the root command (since it's not a single person who does this).
>> Around "the root command"? Personally, I'd write a wrapper around the
>> _passwd_ command, partly _because_ more than one person keeps making this
>> mistake.
>
>god damn, jump down my throat why don't you?

Sorry, I wasn't trying to jump down your throat. I was honestly confused by
your word choice.

Okay, so I advised doing the thing you didn't want to do.

>Ok, so it was a poor choice of words.  I thought it was clever.

Sorry, it went straight over my head. After all, "root" does have another
common meaning in Unix-ese.

>My safeguard is another copy of the original root password in the
>/etc/password (or /etc/shadow) file.  I really didn't see it
>as a major foopah.

I don't think it's really that awful, although I do prefer the idea of
training the users to deal with the system properly rather than expecting
it to read their minds.

-
 Kai MacTane
 System Administrator
  Online Partners.com, Inc.
-
>From the Jargon File: (v4.0.0, 25 Jul 1996)

earthquake /n./ 

[IBM] The ultimate real-world shock test for computer hardware.
Hackish sources at IBM deny the rumor that the Bay Area quake of
1989 was initiated by the company to test quality-assurance
procedures at its California plants. 

Re: poor documentation example

[Racer X]

> *sigh*
>
> You just don't get it... do you.
>
> I have a standard compiler set up.  I have gcc.  I do not have cc.

ahem.  earlier you were complaining about "cc" being installed on solaris
but not working because hey, guess what, it WASN'T really installed.  now
you are saying that you have a "standard" compiler setup involving gcc.

gcc is not a "standard" compiler on anything but linux or *bsd, and on
those systems it's set up by default so that "cc" invokes "gcc", which
means that your argument about "cc" not working doesn't really hold water.

if you want to play a game of semantics, you'd better get your facts and
your words straight.

shag

Re: poor documentation example

[Scott D. Yelich]

> >the root command (since it's not a single person who does this).
> Around "the root command"? Personally, I'd write a wrapper around the
> _passwd_ command, partly _because_ more than one person keeps making this
> mistake.

god damn, jump down my throat why don't you?
People miss my humor so much I sometimes think I'm not funny.

Main Entry: 1root
Pronunciation: 'r|t, 'rut
Function: noun

3 a : something that is an origin or source (as of a condition or
quality)  b : one or more progenitors of a group of
descendants -- usually used in plural c : an underlying support : BASIS
d : the essential core : HEART -- often used in the phrase at root e :
close relationship with an environment : TIE -- usually used in plural


3(d)

Ok, so it was a poor choice of words.  I thought it was clever.

> My preferred wrapper would either prompt when called with no argument
> ("Change the password for the foobar account?"), or perhaps force the user
> to specify an account no matter what ("You must provide an account name!").
> However, another possibility would be to simply have the wrapper get the
> real UID and pass that to passwd as an arg, thus changing the password on
> the account the person su'd from. This means that only those who know how
> to get around the wrapper can change the root password. (Of course, if they
> routinely log in as root from the console, that wouldn't work.)

You're right! That is so much easier than another copy of the 
original root password in the /etc/passwd (/etc/shadow) file.

> Either way, if your users keep screwing up with root power, some kind of
> safeguards need to be put in place.

My safeguard is another copy of the original root password in the
/etc/password (or /etc/shadow) file.  I really didn't see it
as a major foopah.

Scott

Re: poor documentation example

[Kai MacTane]

Text written by Scott D. Yelich at 05:44 PM 3/23/99 -0700:
>
>So, this client owns their own isp.  They have root access.  They often
>type "passwd" without an account to change the password for one of
>their account -- yet they zap the root password.  Ignore my solution --
>how would you prevent this provided that the isp owner will not stop
>using the command and you don't want to write a wrapper for them around
>the root command (since it's not a single person who does this).

Around "the root command"? Personally, I'd write a wrapper around the
_passwd_ command, partly _because_ more than one person keeps making this
mistake.

My preferred wrapper would either prompt when called with no argument
("Change the password for the foobar account?"), or perhaps force the user
to specify an account no matter what ("You must provide an account name!").
However, another possibility would be to simply have the wrapper get the
real UID and pass that to passwd as an arg, thus changing the password on
the account the person su'd from. This means that only those who know how
to get around the wrapper can change the root password. (Of course, if they
routinely log in as root from the console, that wouldn't work.)

Either way, if your users keep screwing up with root power, some kind of
safeguards need to be put in place.

-
 Kai MacTane
 System Administrator
  Online Partners.com, Inc.
-
>From the Jargon File: (v4.0.0, 25 Jul 1996)

Godzillagram /god-zil'*-gram/ /n./ 

[from Japan's national hero] 1. A network packet that in theory is
a broadcast to every machine in the universe... Fortunately, few
gateways are foolish enough to attempt to implement this case!
2. A network packet of maximum size...

Re: poor documentation example

[Russ Allbery]

(If I sound upset, btw, I'm not.  So don't read that into tone; it's not
meant.)

Scott D Yelich <[EMAIL PROTECTED]> writes:

> hahah fine.  I'll leave it at the code that I used to benchmark sun
> ultra code from sunpro-cc and gcc -- the sunpro-cc was 20% faster.
> That's how I base my opinion.  I'm sure there are other factors.

Yes, like a compiler that works the same and takes the same flags across
the eight different platforms I have to support.

>>  * You're allowing multiple access paths to what should be the most
>>secure account on your system.  You now have *multiple* potentially
>>compromised passwords rather than just one.  You have to check and
>>maintain all of them.  Not good.

> baloney.  If the passwords are the same, then you still only have one
> password.

Whether you set the password to the same thing on all the accounts or not,
there are now multiple privileged password entries.  They *can* be
different (or made different by an attacker).  Keeping more than one thing
secure is harder than keeping one thing secure.

Most of the installations I've seen with multiple UID 0 accounts set the
passwords to different things.  You're being more intelligent about it
than most; that's good.

>>  * Stuff gets confused.  You already gave an example of that yourself.

> Um. no and no.

You said that Solaris has a boot script that does a text check for root
and gets confused if there's a UID 0 account in /etc/passwd before root.

> I am fighting and arguing with people on this list over what I feel
> would be contributions to the overall documentation style of qmail
> components.

No, you're fighting and arguing with people on this list about all sorts
of random other topics.  I've yet to see anyone say that a line in INSTALL
mentioning where to configure the compilers would be a bad thing.

> you are saying the same thing over and over without really providing any
> concrete reasons.

I am giving you a concrete reason.  "People get confused."  You have not
yet encountered people who are confused by this.  I'm glad for that.  I
have.  There are a lot of them.  I've done this before I've seen them get
confused.  I've seen the problems that result.  I think it's a bad idea,
and therefore recommend that other people don't do it.  I'm not going to
break into your machine and remove your extra UID 0 accounts; if you don't
agree with me, that's your lookout.  It's not going to break your system
to have multiple UID 0 accounts; it's quite possible to maintain a system
in that fashion.

> does admintool run the rm-user-home as the user or as root?  how would
> this differ from setting a normal user home to /?

It doesn't.  Don't do that either.  :)

> so, lets argue a second root entry vs remote exploit/access to your
> system via admintool.

admintool isn't an exploit.  admintool is something that people who don't
really understand a Solaris machine use to do things on it.  If you
thoroughly understand your machine, you can do anything you want to it and
probably make it work with enough persistance.  If you want people who are
used to normal Unix systems or people who don't really know what they're
doing to be able to work with your box, in my experience UID 0 accounts
other than root are a bad idea.

> I consult for an ISP that uses sendmail -- sorry, there's no way in hell
> that I'm going to instll qmail due to how non-standard it is and how
> poor the documentation is.

You don't need to defend your choice of an MTA.  I run both qmail and
sendmail and am considering Postfix for other things.  Lots of us are like
that.  It's not a binary choice.  In fact, casting suggestions in terms of
"I can't install qmail because X is broken" tends to be needlessly
inflammatory.

> So, this client owns their own isp.  They have root access.  They often
> type "passwd" without an account to change the password for one of their
> account -- yet they zap the root password.  Ignore my solution -- how
> would you prevent this provided that the isp owner will not stop using
> the command and you don't want to write a wrapper for them around the
> root command (since it's not a single person who does this).

So you have someone with root access who regularly types incorrect
commands as root and is unwilling to learn how to do it right and you
can't take root away from them.

You're right.  Ignore my suggestions about UID 0 accounts; they'll be the
least of your problems.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>

Re: poor documentation example

[Scott D. Yelich]

On 23 Mar 1999, Russ Allbery wrote:
> Sam <[EMAIL PROTECTED]> writes:
> > "Standard Solaris machine" is not the same thing as a "Standard UNIX
> > machine".  A standard UNIX machine comes with a functioning C compiler.
> Solaris doesn't.  HP-UX comes with something that's functioning only under
> the most general possible definition of the term.  I don't believe AIX
> does.  IRIX doesn't even come with header files, let alone a compiler.
> Linux and *BSD come with functioning C compilers.


This may not be the place to ask... and I'm not sure I'd like
the answers -- but I'll ask anyway:

(1) is it standard (practice) to link cc to gcc? (and who says it is
standard practice?)
and
(2) how many people here have done this?

As far as linking cc to gcc breaking things.  I'll provide examples.
Say, was the SunOS cc ansi compatible?  I really do remember
commany line options to cc that didn't work with gcc and 
vice-versa.

Scott

Re: poor documentation example

[Scott D. Yelich]

> Scott D Yelich <[EMAIL PROTECTED]> writes:
> >> Don't create multiple UID 0 accounts.  You'll horribly regret it later.
> >> Been there, done that.

> > Why do people say this? What the hell does it matter?
>  * Those extra accounts look like normal accounts but can't be dealt with
>via normal account management policies.  Real example (yes, this
>actually happened):  Someone was cleaning up after an employee who left
>the company and was using admintool to delete his accounts (yes, I
>know, first mistake...).  Deleted the UID 0 account.  Checked the box
>for "remove home directory" since it was the default.  Whoops.

(Sorry this is old, please don't panic!)

export list for 36.93.0.22:
/usr  (everyone)
/usr1 (everyone)
/usr2 (everyone)
dontpanic[17]% iphost !$
iphost 36.93.0.22
finch.Stanford.EDU

wyse2:#hack   f0rcedH   [EMAIL PROTECTED] (Operator)

I don't think it would be good to post password files from stanford
or the old root passwords.  I'm sure things have changed since then. 

Thank goodness.

I think the point of your statements is that perhaps it's not standard
to have multiple root entries just as you shouldn't export your
filesystems to the world.  If you know what you're doing, then it
doesn't really matter unless someone comes along who doesn't know
what they're doing.  Gee, I'm saying the exact same thing.  Perhaps
people come along that just don't know how to deal with the source.

I'm sorry, but I have to consult for people who have their own "root"
access, but who don't know to do much more than vi html files.  These
people are not the ones trying to compile qmail, etc., but there are
some people who are trying to progress from just about that level and
they are getting confused with the lack of documentation in qmail. 

Scott
ps: the issue is not that I can't get qmail to compile -- I can.
I can't get the rbl patches to apply -- but I was told that they
were superceded with rblsmpt.  Fine, I can apply the patches
by *hand*, but that's a lot of work.  So, I'll go with rblsmtpd
(and now tcpserver just for rblsmtpd).  No problem.  It does compile
(and I guess install) since the installs don't ever seem to output
any information.

Re: poor documentation example

[Russ Allbery]

Mark Delany <[EMAIL PROTECTED]> writes:
> At 04:32 PM Tuesday 3/23/99, Russ Allbery wrote:

>> Mark, that's a standard compiler setup for a Solaris machine.  Seriously.

> What?! That the compiler is called gcc is a standard Solaris setup? Now
> I don't understand. None of the Solaris machines I have access to come
> installed with gcc as standard.

I'm making a distinction between "stock" and "standard" that you may not
be.  To me, "standard" in this context is "what I expect to see on a
normal Solaris machine."  Pretty much everyone who runs lots of Solaris
machines installs gcc sooner or later.

> Now, if I hack around and install non-standard stuff, I may end up with
> a gcc and maybe even a link to that from cc, but as I said, I'd call
> that non-standard and wouldn't expect an independent software bundle to
> know that that's what I'd been doing to my system.

Most free software figures it out, since autoconf copes fine.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>

Re: poor documentation example

[Russ Allbery]

Sam <[EMAIL PROTECTED]> writes:

> "Standard Solaris machine" is not the same thing as a "Standard UNIX
> machine".  A standard UNIX machine comes with a functioning C compiler.

Solaris doesn't.  HP-UX comes with something that's functioning only under
the most general possible definition of the term.  I don't believe AIX
does.  IRIX doesn't even come with header files, let alone a compiler.

Linux and *BSD come with functioning C compilers.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>

Re: poor documentation example

[Scott D. Yelich]

> Scott D Yelich <[EMAIL PROTECTED]> writes:
> > bingo.  Lets say I had your setup.  Fine, I type make and it uses "cc"
> > ..  which, if it's sunpro, is better than gcc anyway,
> That's a matter of opinion.

hahah fine.  I'll leave it at the code that I used
to benchmark sun ultra code from sunpro-cc and gcc --
the sunpro-cc was 20% faster.  That's how
I base my opinion.  I'm sure there are other factors.

> > but *if* I wanted to compile using gcc? How would I do that? I'd have to
> > dig through the source until I found the "tricks" ...
> 
> I read the install file and noted that it talked about modifying lots of
> files that started with conf-.  I thought "huh, wonder what all there is."
> I did an ls conf-*, saw conf-cc and conf-ld, figured I'd better edit them,
> and did.

ucp* install mentions conf-home, but not others. sorry.

> >> Don't create multiple UID 0 accounts.  You'll horribly regret it later.
> >> Been there, done that.
> 
> > Why do people say this? What the hell does it matter?
> 
>  * You're allowing multiple access paths to what should be the most secure
>account on your system.  You now have *multiple* potentially
>compromised passwords rather than just one.  You have to check and
>maintain all of them.  Not good.

baloney.  If the passwords are the same, then you still only
have one password.

>  * Stuff gets confused.  You already gave an example of that yourself.

Um. no and no.  *I* am not confused.  I am fighting and arguing with
people on this list over what I feel would be contributions to the
overall documentation style of qmail components.  
nothing gets confused with a second root entry.

>  * You lose simple auditing.  Rather than checking for root logins, you
>now have to check for logins on a bunch of random accounts.

Not true.  Did I say the shell was interactive?

>  * No one expects there to be multiple UID 0 accounts, since that's not
>the way a Unix system normally works.  So they do things under the
>assumption there's only one UID 0 account and you can get security
>holes that way.

you are saying the same thing over and over without really providing
any concrete reasons.

>  * Those extra accounts look like normal accounts but can't be dealt with
>via normal account management policies.  Real example (yes, this
>actually happened):  Someone was cleaning up after an employee who left
>the company and was using admintool to delete his accounts (yes, I
>know, first mistake...).  Deleted the UID 0 account.  Checked the box
>for "remove home directory" since it was the default.  Whoops.

does admintool run the rm-user-home as the user or as root?
how would this differ from setting a normal user home to /?

so, lets argue a second root entry vs remote exploit/access
to your system via admintool.  

Fine.  This is the qmail mailing list.  I'm trying to talk about qmail
-- but we're side tracked. 

I consult for an ISP that uses sendmail -- sorry, there's no way in hell
that I'm going to instll qmail due to how non-standard it is and how
poor the documentation is.  It's ok, for *me* because I have fought with
it and I canuse it, but for anyone else coming it, it's "not standard"
and I think it's in poor taste to do that to a client. 

So, this client owns their own isp.  They have root access.  They often
type "passwd" without an account to change the password for one of
their account -- yet they zap the root password.  Ignore my solution --
how would you prevent this provided that the isp owner will not stop
using the command and you don't want to write a wrapper for them around
the root command (since it's not a single person who does this).

Anyway, I'll now install tcpserver and see how long my mail is down.
I'll report back.

Scott

Re: poor documentation example

[Mark Delany]

At 04:32 PM Tuesday 3/23/99, Russ Allbery wrote:
>Mark Delany <[EMAIL PROTECTED]> writes:
>> At 05:10 PM Tuesday 3/23/99, Scott D. Yelich wrote:
>
>>> I have a standard compiler set up.  I have gcc.  I do not have cc.
>
>> Ahh. You mean you have a NON-standard compiler setup. Now I understand.
>
>Mark, that's a standard compiler setup for a Solaris machine.  Seriously.

What?! That the compiler is called gcc is a standard Solaris setup? Now I 
don't understand. None of the Solaris machines I have access to come 
installed with gcc as standard.

Now, if I hack around and install non-standard stuff, I may end up with a 
gcc and maybe even a link to that from cc, but as I said, I'd call that 
non-standard and wouldn't expect an independent software bundle to know that 
that's what I'd been doing to my system.


Regards.

Re: poor documentation example

[Sam]

Scott D. Yelich writes:

> 
> > > chmod 755 compile
> > > ./compile tcpclient.c
> > > ./compile: cc: not found
> > > *** Error code 1
> > Bad example.
> 
> not a bad example.  get a standard solaris machine (without 
> paying for sun's sunpro cc) and install gcc.

"Standard Solaris machine" is not the same thing as a "Standard UNIX
machine".  A standard UNIX machine comes with a functioning C compiler.

> > This is a minor glitch.  Although it's real cause is your broken C
> > compiler, let's say that's even not case.  Things like this happen all the
> > time, and I don't see the big deal about it.
> 
> I do not have a broken C compiler.  You can say it as much and as 
> often as you like, but that doesn't make it any more true.

Well, it is true.  Your C compiler is broken. "cc" has been used on UNIX to
invoke a functioning C compiler since the dark ages.  No matter how often
you claim it, that historical fact won't go away.  When you have software
that should work on most UNIX systems, you don't go in and hardcode in
features that are specific to only one common UNIX flavor.  You go for the
least common denominator, which happens to be cc.

Do you think that people should go around putting out stuff that's
hardcoded for gcc?

> Why does one have to read the qmail FAQ just to be able to 
> install qmail  Can you answer that?

Nope.  I've installed Qmail without reading the FAQ.  With selective
relaying, and all that.  Granted, my selective relaying solution wasn't the
best one, but you can't have everything.

-- 
Sam

Re: poor documentation example

[Russ Allbery]

Mark Delany <[EMAIL PROTECTED]> writes:
> At 05:10 PM Tuesday 3/23/99, Scott D. Yelich wrote:

>> I have a standard compiler set up.  I have gcc.  I do not have cc.

> Ahh. You mean you have a NON-standard compiler setup. Now I understand.

Mark, that's a standard compiler setup for a Solaris machine.  Seriously.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>

Re: poor documentation example

[Mark Delany]

At 05:10 PM Tuesday 3/23/99, Scott D. Yelich wrote:
>> I've had tcpserver compile just fine even with HP's broken compiler.  It
>> seems as if you're trying to find fault just to try and prove your point.
>> If you know/knew in advance of your non-standard compiler setup you'd be
>> prepared for it.
>
>*sigh*
>
>You just don't get it... do you.
>
>I have a standard compiler set up.  I have gcc.  I do not have cc.

Ahh. You mean you have a NON-standard compiler setup. Now I understand.


Regards.

Re: poor documentation example

[Stefan Paletta]

Scott D. Yelich wrote/schrieb/scribsit:

> ./Configure is nice... but it's not the only way.  Dan's way works --
> once you've dug through the source.  Gee, one line in the install/readme
> would prevent this.

stefanp@horatio[qmail-1.03]$ head -1 Makefile
# Don't edit Makefile! Use conf-* for configuration.

Stefan

Re: poor documentation example

[Russ Allbery]

Scott D Yelich <[EMAIL PROTECTED]> writes:

> Why does one have to read the qmail FAQ just to be able to install qmail
> Can you answer that?

Please name a fully-functional Internet MTA for which you do not have to
read the documentation to install it.

RPMs don't count.

(Yes, I agree with you that a line in INSTALL about configuring the
compiler and linker is appropriate.  But the statements you're using to
support your argument are going too far.)

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>

Re: poor documentation example

[Russ Allbery]

Scott D Yelich <[EMAIL PROTECTED]> writes:

> bingo.  Lets say I had your setup.  Fine, I type make and it uses "cc"
> ..  which, if it's sunpro, is better than gcc anyway,

That's a matter of opinion.

> but *if* I wanted to compile using gcc? How would I do that? I'd have to
> dig through the source until I found the "tricks" ...

I read the install file and noted that it talked about modifying lots of
files that started with conf-.  I thought "huh, wonder what all there is."
I did an ls conf-*, saw conf-cc and conf-ld, figured I'd better edit them,
and did.

It could stand a single line at the top of INSTALL, sure.

But if you actually read the make output after it fails:

( cat warn-auto.sh; \
echo CC=\'`head -1 conf-cc`\'; \
echo LD=\'`head -1 conf-ld`\' \
) > auto-ccld.sh

is kinda obviously pointing at the files to change, I'd say.

>> Don't create multiple UID 0 accounts.  You'll horribly regret it later.
>> Been there, done that.

> Why do people say this? What the hell does it matter?

 * You're allowing multiple access paths to what should be the most secure
   account on your system.  You now have *multiple* potentially
   compromised passwords rather than just one.  You have to check and
   maintain all of them.  Not good.

 * Stuff gets confused.  You already gave an example of that yourself.

 * You lose simple auditing.  Rather than checking for root logins, you
   now have to check for logins on a bunch of random accounts.

 * No one expects there to be multiple UID 0 accounts, since that's not
   the way a Unix system normally works.  So they do things under the
   assumption there's only one UID 0 account and you can get security
   holes that way.

 * Those extra accounts look like normal accounts but can't be dealt with
   via normal account management policies.  Real example (yes, this
   actually happened):  Someone was cleaning up after an employee who left
   the company and was using admintool to delete his accounts (yes, I
   know, first mistake...).  Deleted the UID 0 account.  Checked the box
   for "remove home directory" since it was the default.  Whoops.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>

Re: poor documentation example

[Scott D. Yelich]

> > chmod 755 compile
> > ./compile tcpclient.c
> > ./compile: cc: not found
> > *** Error code 1
> Bad example.

not a bad example.  get a standard solaris machine (without 
paying for sun's sunpro cc) and install gcc.

try to compile anything of dans for the first time
(ie; first time compile, not new software 
for the first time).  I work with admins who just
can't figure out his compiling mechanism.

> If you do not have a functioning C compiler installed on your system, you
> have no business compiling or installing any software, not just Qmail.

I have never said that I do not have a functioning C compiler.
You have said and assumed this.  You have assumed incorrectly.

> > and see that games being played with conf-cc ...
> > but then ld will fail, and I'll have to do the same for that after
> > the make fails.
> > Why not mention *this* in this INSTALL?
> Why make so much fuss about this?

Why?  because it's necessary in order to compile?

> This is a minor glitch.  Although it's real cause is your broken C
> compiler, let's say that's even not case.  Things like this happen all the
> time, and I don't see the big deal about it.

I do not have a broken C compiler.  You can say it as much and as 
often as you like, but that doesn't make it any more true.

> The only item I'll agree with you on is that djb should be using GNU
> auto-bloat, in order to handle convoluted compilers like that.


./Configure is nice... but it's not the only way.  Dan's way works --
once you've dug through the source.  Gee, one line in the install/readme
would prevent this.

Why does one have to read the qmail FAQ just to be able to 
install qmail  Can you answer that?

Scott

Re: poor documentation example

[James Smallacombe]

On Tue, 23 Mar 1999, Scott D. Yelich wrote:

> > I've had tcpserver compile just fine even with HP's broken compiler.  It
> > seems as if you're trying to find fault just to try and prove your point.
> > If you know/knew in advance of your non-standard compiler setup you'd be
> > prepared for it.
> 
> *sigh*
> 
> You just don't get it... do you.
> 
> I have a standard compiler set up.  I have gcc.  I do not have cc.

The first thing I do after I install gcc on a new Solaris box is symlink
cc to gcc.  I recall you saying that this breaks things, but I haven't had
a problem with it.

> I get 99% of my programs in source and they tell me to 
> edit the Make file and change the "cc" line to "gcc"
> or to type ./Configure.  Both of these get me to 
> compile (maybe I have to define solaris, etc.) just
> fine.

So does linking gcc to cc.

> Then comes qmail, et al., does it use Makefile with
> CC=gcc? no.  Does it use ./Configure? no.  It says
> "type make; make config check; # that's all!"

No, it doesn't.  It doesn't need to, since it doesn't have a bazillion
compile-time options (I kinda wish it did, but that's another story).

> BUT IT IS NOT ALL.
> 
> That's all (I'm trying to say).  

Okay, okay, you've said it.  That being said, tcpserver is the quickest
and easiest piece of software I've ever built and installed.  YMMV

James SmallacombeInternet Access for The Delaware
[EMAIL PROTECTED]Valley in PA, NJ and DE
PlantageNet Internet Ltd.http://www.pil.net
=
ISPF 3 - The Forum for ISPs by ISPs(tm)  ||  Nov 15-17, 1999, New Orleans
3 days of clues, news, and views from the industry's best and brightest.
 Visit  for information and registration.
=

Re: poor documentation example

[Sam]

Scott D. Yelich writes:

[ snip ]

> chmod 755 compile
> ./compile tcpclient.c
> ./compile: cc: not found
> *** Error code 1

Bad example.

If you do not have a functioning C compiler installed on your system, you
have no business compiling or installing any software, not just Qmail.

[ snip ]

> and see that games being played with conf-cc ...
> but then ld will fail, and I'll have to do the same for that after
> the make fails.
> 
> Why not mention *this* in this INSTALL?

Why make so much fuss about this?

This is a minor glitch.  Although it's real cause is your broken C
compiler, let's say that's even not case.  Things like this happen all the
time, and I don't see the big deal about it.

The only item I'll agree with you on is that djb should be using GNU
auto-bloat, in order to handle convoluted compilers like that.

-- 
Sam

Re: poor documentation example

[Scott D. Yelich]

> Everything that you have to compile depends on the name of the C compiler.
> I edited conf-cc and conf-ld once when I was first building qmail, saved
> it as a local patch, and problem was forever solved.  One gets very used
> to doing that on Solaris to get things to compile with gcc instead,
> particularly given that I *have* cc (/opt/SUNWspro/bin/cc, to be precise).

bingo.  Lets say I had your setup.  Fine, I type make and it uses "cc"
..  which, if it's sunpro, is better than gcc anyway, but *if* I wanted
to compile using gcc? How would I do that? I'd have to dig through the
source until I found the "tricks" ... 

*I* kow the tricks.  As someone else said, every since first struggling
with it when trying to compile qmail, I have known to look for
conf (in fact, I look for conf* and */conf*) just to look around.

> > You know, solaris boot has a check for the current user to be "root" so
> > if you put another entry in the /etc/passwd *before* root with uid 0, a
> > solaris system won't boot?  Isn't that kind of pathetic?  Why can't the
> > script check "id" or something for the uid instead of depending on the
> > *text* output of some user check?
> Don't create multiple UID 0 accounts.  You'll horribly regret it later.
> Been there, done that.

Why do people say this? What the hell does it matter? People these days
spout a bunch of baseless crap.   If you want to discuss this, I'd be
glad to take it to email to see where we differ in philosophies.

Scott

Re: poor documentation example

[Scott D. Yelich]

> I've had tcpserver compile just fine even with HP's broken compiler.  It
> seems as if you're trying to find fault just to try and prove your point.
> If you know/knew in advance of your non-standard compiler setup you'd be
> prepared for it.

*sigh*

You just don't get it... do you.

I have a standard compiler set up.  I have gcc.  I do not have cc.

I get 99% of my programs in source and they tell me to 
edit the Make file and change the "cc" line to "gcc"
or to type ./Configure.  Both of these get me to 
compile (maybe I have to define solaris, etc.) just
fine.

Then comes qmail, et al., does it use Makefile with
CC=gcc? no.  Does it use ./Configure? no.  It says
"type make; make config check; # that's all!"

BUT IT IS NOT ALL.

That's all (I'm trying to say).  

Scott

Re: poor documentation example

[Russ Allbery]

Scott D Yelich <[EMAIL PROTECTED]> writes:

> Fine.  Be hostile -- you're not hurting me.  Try any solaris system.

> security [4258]> /usr/ucb/cc
> /usr/ucb/cc:  language optional software package not installed

windlord:~> ls /usr/ucb/cc
ls: /usr/ucb/cc: No such file or directory
windlord:~> uname -a
SunOS windlord.stanford.edu 5.6 Generic_105181-11 sun4u sparc SUNW,Ultra-1

Much better.

> I have gcc, but I don't just link cc to gcc as some systems seem very
> broken when they depend on the name of the "cc" compiler for things.

Everything that you have to compile depends on the name of the C compiler.
I edited conf-cc and conf-ld once when I was first building qmail, saved
it as a local patch, and problem was forever solved.  One gets very used
to doing that on Solaris to get things to compile with gcc instead,
particularly given that I *have* cc (/opt/SUNWspro/bin/cc, to be precise).

> You know, solaris boot has a check for the current user to be "root" so
> if you put another entry in the /etc/passwd *before* root with uid 0, a
> solaris system won't boot?  Isn't that kind of pathetic?  Why can't the
> script check "id" or something for the uid instead of depending on the
> *text* output of some user check?

Don't create multiple UID 0 accounts.  You'll horribly regret it later.
Been there, done that.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>

Re: poor documentation example

[Vince Vielhaber]

On 23-Mar-99 Scott D. Yelich wrote:
>> > Why not mention *this* in this INSTALL?
>> > How many people here had to ask or figure this out for
>> > themselves provided that they didn't have "cc" working?
>> Uh, you're kidding, right?
>> I think the assumption is that you won't be messing around with compiling a
>> new mail server (or anything else for that matter) from scratch if you
>> can't even figure out your compiler.  I've yet to find a stock system with
>> development tools installed where "cc" didn't invoke the compiler.
> 
> Fine.  Be hostile -- you're not hurting me.  Try any solaris system.
> 
> security [4258]> /usr/ucb/cc
> /usr/ucb/cc:  language optional software package not installed
> 
> I have gcc, but I don't just link cc to gcc as some systems
> seem very broken when they depend on the name of the "cc" 
> compiler for things.
> 
> You know, solaris boot has a check for the current user to be "root"
> so if you put another entry in the /etc/passwd *before* root
> with uid 0, a solaris system won't boot?  Isn't that kind of
> pathetic?  Why can't the script check "id" or something for
> the uid instead of depending on the *text* output of
> some user check?

Just guessing, but I bet you'd bitch if you were hung with a new rope.

I've had tcpserver compile just fine even with HP's broken compiler.  It
seems as if you're trying to find fault just to try and prove your point.
If you know/knew in advance of your non-standard compiler setup you'd be
prepared for it.

Vince.
-- 
==
Vince Vielhaber -- KA8CSH   email: [EMAIL PROTECTED]   flame-mail: /dev/null
   # includeTEAM-OS2
Online Campground Directoryhttp://www.camping-usa.com
   Online Giftshop Superstorehttp://www.cloudninegifts.com
==

Re: poor documentation example

[Scott D. Yelich]

> > Why not mention *this* in this INSTALL?
> > How many people here had to ask or figure this out for
> > themselves provided that they didn't have "cc" working?
> Uh, you're kidding, right?
> I think the assumption is that you won't be messing around with compiling a
> new mail server (or anything else for that matter) from scratch if you
> can't even figure out your compiler.  I've yet to find a stock system with
> development tools installed where "cc" didn't invoke the compiler.

Fine.  Be hostile -- you're not hurting me.  Try any solaris system.

security [4258]> /usr/ucb/cc
/usr/ucb/cc:  language optional software package not installed

I have gcc, but I don't just link cc to gcc as some systems
seem very broken when they depend on the name of the "cc" 
compiler for things.

You know, solaris boot has a check for the current user to be "root"
so if you put another entry in the /etc/passwd *before* root
with uid 0, a solaris system won't boot?  Isn't that kind of
pathetic?  Why can't the script check "id" or something for
the uid instead of depending on the *text* output of
some user check?

I know you don't see my point.

Scott

Re: poor documentation example

[Racer X]

> Why not mention *this* in this INSTALL?
>
> How many people here had to ask or figure this out for
> themselves provided that they didn't have "cc" working?

Uh, you're kidding, right?

I think the assumption is that you won't be messing around with compiling a
new mail server (or anything else for that matter) from scratch if you
can't even figure out your compiler.  I've yet to find a stock system with
development tools installed where "cc" didn't invoke the compiler.

shag

poor documentation example

[Scott D. Yelich]

> Perhaps tcpserver or the docs are just intimidating.  I know I was a bit
> reluctant to use it at first, now I find myself using it for just about
> everything - including backups, passing encrypted data between hosts, etc.
> It's really handy!  Thanks Dan!!


Example:

ucwhatever INSTALL instructions:

spy [4246]> less INSTALL 
Like any other piece of software (and information generally), ucspi-tcp
comes with NO WARRANTY.


Things you have to decide before starting:

* The ucspi-tcp home directory, normally /usr/local. To change this
directory, edit conf-home now.


How to install:

 1. Compile the programs and create the formatted man pages:
   % make

 2. Install the programs and man pages:
   # make setup check


That's it! To report success:
   % ( echo 'First M. Last'; cat `cat SYSDEPS` ) | mail [EMAIL PROTECTED]
Replace First M. Last with your name.


chmod 755 compile
./compile tcpclient.c
./compile: cc: not found
*** Error code 1
make: Fatal error: Command failed for target `tcpclient.o'
spy [4228]> cat compile 
#!/bin/sh
# WARNING: This file was auto-generated. Do not edit!
exec cc -O2 -c ${1+"$@"}


Where does it say edit conf-cc and conf-ld ?
if I cat compile -- it says "cc" but that file is generate?

Of course, I could do something like:
spy [4250]> egrep -i "conf\-cc" *
FILES:conf-cc
Makefile:warn-auto.sh conf-cc
Makefile:   echo exec "`head -1 conf-cc`" '-c $${1+"$$@"}' \
Makefile:recordio.c argv0.1 argv0.c rts.sh rts.tests rts.exp conf-cc conf-ld \
Makefile:find-systype.sh conf-cc conf-ld trycpp.c
Makefile:   echo CC=\'`head -1 conf-cc`\'; \

and see that games being played with conf-cc ...
but then ld will fail, and I'll have to do the same for that after
the make fails.

Why not mention *this* in this INSTALL?

How many people here had to ask or figure this out for
themselves provided that they didn't have "cc" working?

Scott