Mailing List Archive

+1 on fixing any minor bugs that can be fixed in the scoreboard
mechanisms, and avoiding major surgery until 0.8.7 or 0.9 or whatever.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

> If the server eats dogfood on account of Joe Random Web-admin's setting
> a configuration value too low ( RobH's MAX servers << HARD_SERVER_MAX )
> then I could live with that provided the conf files carried a stong notice
> to the effect of 'DONT PRESS THIS BUTTON'. Ideally of course the server
> should just NEVER let itself get into that position in the first place.

> Could you and Rob discuss this off-line? He has vehemently argued
> that he wants to be able to screw himself in precisely this fashion.
> (WRT MaxClients, the strong notice you ask for is present already).

Wasn't it Brian's comments which got this into Apache ?. I remember
*asking* for it and having the request turned down. Oh dear, this
could slide into dangerous territory. Forget I wrote it.

The configurable MAX stops the server from screwing the OS, and is a
good thing IMO.

Any problems I've had were not caused by screwing myself with a low
MAX, unless the code to handle non-default MAX settings is buggy.


rob

On Wed, 2 Aug 1995, Chuck Murcko wrote:
> > That's not to say that I think the queries about how it works and the
> > code review are inappropriate --- in fact, I was surprised that there
> > wasn't a bit more of that when I first wrote the stuff. But there
> > wasn't...
> >
> If you wait for it to be perfect, it will never be finished.
> It is certainly workable as is.

"The last bug is squished when the last user is dead!" -- i forget

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Hmmm... If I'm going to reply to this, I might as well start by
stating my own opinion --- I really want to get something out soon,
because NCSA 1.5 is in beta, because we've been so long without a
release, and because we've been talking the thing up and saying "soon"
to too many people, including a reporter, barring real show-stopper
bugs. This would probably not be a perfect release, but perfection is
not an option anyway --- it's a beta, and it will inevitably have bugs
which we will have to fix reasonably quickly, even if we don't know
what they are yet; I don't see perfection as an option, and that
shapes my attitude toward waiting till we're sure it's perfect.

I think 0.8.6 works well enough to release *as a beta*, barring some
major show-stopper bugs; comments on the ones we know about below. I
don't want to wait another week, and I don't want to do major surgery
on the scoreboard code now, which would be longer than that before I
thought it was even as stable as the current version (whatever bugs
may exist and all), unless there is a specific, easy fix to some part
of it that's clearly wrong. But, reasonable people might disagree,
which is why I posed the question.

Now, in response to Andrew...

Date: Wed, 2 Aug 95 22:33:53 BST
From: Andrew Wilson <andrew@www.elsevier.co.uk>

If there's a possible security flaw introduced as a result of rogue
permissions on the scoreboard file then that should really be fixed before
things go any further. ( Zeroable file causing fork bombing perhaps).

This is an trivial fix... I could easily respin 0.8.6 tonight to
include it, and this might well be a good idea.

If the server eats dogfood on account of Joe Random Web-admin's setting
a configuration value too low ( RobH's MAX servers << HARD_SERVER_MAX )
then I could live with that provided the conf files carried a stong notice
to the effect of 'DONT PRESS THIS BUTTON'. Ideally of course the server
should just NEVER let itself get into that position in the first place.

Could you and Rob discuss this off-line? He has vehemently argued
that he wants to be able to screw himself in precisely this fashion.
(WRT MaxClients, the strong notice you ask for is present already).

Whatever, it sound's like RobH for one has got a real rat's nest on his
hands. It'd be nice to know things were clear for his HP's before
proceeding.

The question is whether there's something which is preventing the
scoreboard mechanism from working AT ALL on the HP's. Worse come to
worst, I could try this myself after hours with the HPs downstairs
(though that's a bit more difficult now); the question is whether the
scoreboard mechanism works at all --- which should be an easy test;
set MaxClients to some reasonable value, set MaxSpareServers low,
bombard it with requests, and see if the server pool dies back when
the pummeling is over. Rob?

Mm, all this aside, Apache just keeps getting better and better. Yummy.

Sigh... I've put a whole lot of work into it myself, and I would like
it to have a larger audience than the members of this mailing list,
but unless we release it (or if we unreasonably delay releasing it),
that won't happen.

If it's worth showing off, let's show it off. If it isn't, let's
quit.

rst

0.8.6 is ready for public release. It's a fine piece of code
and one the group should be proud of.

+1 to announce

On Wed, 02 Aug 1995 20:32:59 -0500 Randy Terbush wrote:
> 0.8.6 is ready for public release. It's a fine piece of code
> and one the group should be proud of.
>
> +1 to announce

+1 from me as well.

This is what has me really frustrated... IMHO, it *has* been tested as
thoroughly as I think we can test it --- we've run it on a fairly wide
variety of machines to which we have access, some of which get fairly
heavy loads, for more than a week, and it does appear to be at least
as stable, in its present state, as anyone else's typical beta code.

That's not to say that I think the queries about how it works and the
code review are inappropriate --- in fact, I was surprised that there
wasn't a bit more of that when I first wrote the stuff. But there
wasn't...

rst

I came back tonight to check for yesterday's problem. No sign of it.

There's no point waiting for it to happen again, so lets launch.


Is it worth numbering it 0.9 for release ?.. it might give people
an idea that it's closing in on being our first non-beta, and it draws
an obvious line between released (0.9+) and pre-release (0.8*) stuff.
I bet Rob's sick of these little rebuilds, so it's understandable if
the number stays as is, it's no big deal.


rob

>
>
> I came back tonight to check for yesterday's problem. No sign of it.
>
> There's no point waiting for it to happen again, so lets launch.
>
>
> Is it worth numbering it 0.9 for release ?.. it might give people
> an idea that it's closing in on being our first non-beta, and it draws
> an obvious line between released (0.9+) and pre-release (0.8*) stuff.
> I bet Rob's sick of these little rebuilds, so it's understandable if
> the number stays as is, it's no big deal.
>
>
> rob

In order to give some of the mirror sites a chance to grab copies
before the announcement, we should probably roll with 0.8.6. I had
the same thoughts as I was updating the web pages to reflect the
release. Anybody have any new docs? Looks like we will be
scrambling to pull some of this together over then next day or so...

I made some changes to the top page. Check out www.apache.org/newindex.
Shoot me if you don't like it. I need to do some image cleanup in the
morning as I have some rather ragged edges.

We can probably release with 0.9 in a week or so after handling
a few bugs....

> So, where do we stand?
> In particular, how do people feel about releasing 0.8.6 as is, and how
> many want it to wait until the scoreboard cleanup (which would
> probably take another few days at least, assuming we trust the new
> code to work right off the bat)?

There's no point releasing anything that will definately need an immediate
fix. Cuz it'll just have to be, er, immediately fixed and we end up looking
like idiots for releasing (and announcing it) in the first place.

If there's a possible security flaw introduced as a result of rogue
permissions on the scoreboard file then that should really be fixed before
things go any further. ( Zeroable file causing fork bombing perhaps).

If the server eats dogfood on account of Joe Random Web-admin's setting
a configuration value too low ( RobH's MAX servers << HARD_SERVER_MAX )
then I could live with that provided the conf files carried a stong notice
to the effect of 'DONT PRESS THIS BUTTON'. Ideally of course the server
should just NEVER let itself get into that position in the first place.

Coding style and performance issues wouldn't bother me, provided that
the performance hit isn't too great. ( waitpid relying on supposed
default behaviour of a kernel call, wait ).

Whatever, it sound's like RobH for one has got a real rat's nest on his
hands. It'd be nice to know things were clear for his HP's before
proceeding.

> rst

Mm, all this aside, Apache just keeps getting better and better. Yummy.

Ay.

rst:
> Now, in response to Andrew...

Woo, that's me!

> Date: Wed, 2 Aug 95 22:33:53 BST
> From: Andrew Wilson <andrew@www.elsevier.co.uk>
>
> If there's a possible security flaw introduced as a result of rogue
> permissions on the scoreboard file then that should really be fixed before
> things go any further. ( Zeroable file causing fork bombing perhaps).
>
> This is an trivial fix... I could easily respin 0.8.6 tonight to
> include it, and this might well be a good idea.

Ok +1 for the fix.

> If the server eats dogfood on account of Joe Random Web-admin's setting
> a configuration value too low ( RobH's MAX servers << HARD_SERVER_MAX )
> then I could live with that provided the conf files carried a stong notice
> to the effect of 'DONT PRESS THIS BUTTON'. Ideally of course the server
> should just NEVER let itself get into that position in the first place.
>
> Could you and Rob discuss this off-line? He has vehemently argued
> that he wants to be able to screw himself in precisely this fashion.
> (WRT MaxClients, the strong notice you ask for is present already).

He's a big boy, he can hack the server some if he really wants to play
about with MAX setting. Anyway he might learn something useful for future
releases. My concern is only that people shouldn't accidently be able to
trash their server. If they recompile a kludge then that's their problem.

I guess this means things are ok.

> Whatever, it sound's like RobH for one has got a real rat's nest on his
> hands. It'd be nice to know things were clear for his HP's before
> proceeding.
>
> The question is whether there's something which is preventing the
> scoreboard mechanism from working AT ALL on the HP's. Worse come to
> worst, I could try this myself after hours with the HPs downstairs
> (though that's a bit more difficult now); the question is whether the
> scoreboard mechanism works at all --- which should be an easy test;
> set MaxClients to some reasonable value, set MaxSpareServers low,
> bombard it with requests, and see if the server pool dies back when
> the pummeling is over. Rob?
>
> Mm, all this aside, Apache just keeps getting better and better. Yummy.
>
> Sigh... I've put a whole lot of work into it myself, and I would like
> it to have a larger audience than the members of this mailing list,
> but unless we release it (or if we unreasonably delay releasing it),
> that won't happen.

I think we all appreciate the work you've been doing recently and I'm happy
to have contributed a little, albeit with a few innane suggestions. You are
of course at liberty to release whatever you want, to whoever you want,
whenever you want. We all are in this respect since the damned thing's
public property. ;)

However, wanting to release something doesn't make it less likely to be
flawed. Apache's a complex system now, with a very few elements that might
benefit from a more thorough test. The bigger the system gets the more
testing it needs and so the more the time that is needed before a release.
Getting frustated by the wait is all a part of this.

> If it's worth showing off, let's show it off. If it isn't, let's
> quit.

You don't want to quit do you? Nope, I didn't think so. So show it off.
I'm happy with the server now. I wouldn't mind it being released.

> rst

Cheers,
Ay.

Andrew Wilson URL: http://www.cm.cf.ac.uk/User/Andrew.Wilson/
Elsevier Science, Oxford Office: +44 01865 843155 Mobile: +44 0589 616144

On Wed, 2 Aug 1995, Randy Terbush wrote:
> I made some changes to the top page. Check out www.apache.org/newindex.
> Shoot me if you don't like it. I need to do some image cleanup in the
> morning as I have some rather ragged edges.

The black background is a good way to ensure that people know something
has changed - we should have a "What's New with Apache" page as well I
suppose.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

TransferLog | program
does not work; apache hangs on a restart.

[. goes to directory with "one-of-everything" (Virtual Hosts, Transferlog |,
etc.) test setup ]
[ kicks off server ]
[ tries restart ]
[ ooops ]

... probably not. Here's a patch, which seems to cure the problem; I
only hope it doesn't introduce anything worse:

*** /com/web/src/apache_0.8.6/src/http_main.c Wed Aug 2 20:38:45 1995
--- http_main.c Thu Aug 3 08:38:05 1995
***************
*** 423,432 ****
void reclaim_child_processes ()
{
int i, status;

sync_scoreboard_image();
! for (i = 0; i < HARD_SERVER_MAX; ++i)
! waitpid (scoreboard_image[i].pid, &status, 0);
}

/* Finally, this routine is used by the caretaker process to wait for
--- 423,437 ----
void reclaim_child_processes ()
{
int i, status;
+ int my_pid = getpid();

sync_scoreboard_image();
! for (i = 0; i < HARD_SERVER_MAX; ++i) {
! int pid = scoreboard_image[i].pid;
!
! if (pid != my_pid && pid != 0)
! waitpid (scoreboard_image[i].pid, &status, 0);
! }
}

/* Finally, this routine is used by the caretaker process to wait for

> Actually, I really don't like the new colour scheme. It looks too much like
> a Megadeath T-shirt.

:-)

Yup, it's eye-catching.. like a sharp stick.


rob

Please apply liberal amounts of ;-) to my mail.

> +1 on fixing any minor bugs that can be fixed in the scoreboard
> mechanisms, and avoiding major surgery until 0.8.7 or 0.9 or whatever.
>
> Brian

+1 for me too.

Ay.

The only forced background colour I've ever seen which works well
is white. It adds clarity to pages, but can give you snow blindness
after prolonged use.

I think Netscape++ will allow users to choose background colours, so
picking odd foreground colours to suit a background will backfire when
user choice wins.


rob

Brian:
> On Wed, 2 Aug 1995, Randy Terbush wrote:
> > I made some changes to the top page. Check out www.apache.org/newindex.
> > Shoot me if you don't like it. I need to do some image cleanup in the
> > morning as I have some rather ragged edges.
>
> The black background is a good way to ensure that people know something
> has changed - we should have a "What's New with Apache" page as well I
> suppose.

I'm not sure I like the new colour scheme, but then I don't get bothered
by background goofiness when I use NS1.0N.

Actually, I really don't like the new colour scheme. It looks too much like
a Megadeath T-shirt.

If you reeeely want to recolour the links (I think you just plain shouldn't,
as people grow up knowing that blue means link and purple means you've already
been there) then don't make the _already_seen_ links the same colour as the
normal text. I find myself having to scan the cursor over all the text
looking for links.

Hey I come from COMMA. Blood gets spilled every time someone tries to
change the homepage there.

Naaah, it just looks cheesy.

Ay (going for the 'love me' vote)

Andrew Wilson URL: http://www.cm.cf.ac.uk/User/Andrew.Wilson/
Elsevier Science, Oxford Office: +44 01865 843155 Mobile: +44 0589 616144

> I think Netscape++ will allow users to choose background colours, so
> picking odd foreground colours to suit a background will backfire when
> user choice wins.

> Ummm... let's give Netscape a little credit here --- the *current*
> version allows users to change background and anchor colors via X

but I hear it's going to be *easy* to change them. Most people won't
touch an X resource file with a barge pole.

As I've already said,
TransferLog | program
does not work; apache hangs on a restart.
Do folks _really_ want to release apache with this bug? We should at least
mention that it does not work. Vote please?

David.

Agreed on the color choices, I'm afraid... particularly the link colors.
(Blue on black tends to be pretty hard to read --- blue receptors are more
thinly distributed on the retina, so you have rather worse acuity for deep
blue than for red & green, unless the blue in question has enough towards
the red end of the spectrum that those show up as well. So a light blue is
OK on black (there's enough red & green to see by), but white on yellow, or
vice versa, can be bad (since the *absence* of blue is the only differ...

Oooops. Psychophysics seeping through. Forget it.

rst

I think Netscape++ will allow users to choose background colours, so
picking odd foreground colours to suit a background will backfire when
user choice wins.

Ummm... let's give Netscape a little credit here --- the *current*
version allows users to change background and anchor colors via X
resources, and to keep their choices from being overridden by any
document, but the same resource which keeps backgrounds from being
overridden (*documentColorsHavePriority) does the same for text
colors as well. So, we don't have to worry (much) about clash
between our text colors and somebody else's background...

rst

but I hear it's going to be *easy* to change them. Most people won't
touch an X resource file with a barge pole.

That would be an improvement --- but anyway, the point was that the
same resource controls overriding *all* color choices, so the user sees
either their own choices for background and text colors, or the document's,
but not a mixture; that's a good idea, and I presume they won't drop it.

That doesn't mean that blue-on-black text is a good idea; it does mean
that the potential of a clash with a user background is not the best reason
to avoid it...

rst

>TransferLog | program
>does not work; apache hangs on a restart.

A patch for this:

------------- begin patch
*** http_main.c~ Thu Aug 3 01:38:45 1995
--- http_main.c Thu Aug 3 14:06:39 1995
***************
*** 426,432 ****

sync_scoreboard_image();
for (i = 0; i < HARD_SERVER_MAX; ++i)
! waitpid (scoreboard_image[i].pid, &status, 0);
}

/* Finally, this routine is used by the caretaker process to wait for
--- 426,433 ----

sync_scoreboard_image();
for (i = 0; i < HARD_SERVER_MAX; ++i)
! if (scoreboard_image[i].status != SERVER_DEAD)
! waitpid (scoreboard_image[i].pid, &status, 0);
}

/* Finally, this routine is used by the caretaker process to wait for
------------- begin patch