William A. Rowe, Jr. wrote:
For anyone who wants to argue that this is a PHP-caused anomaly, note also
http://www.securityspace.com/s_survey/data/man.200501/apachemods.html
-10% followed by +11% the following month:
http://www.securityspace.com/s_survey/data/man.200502/apachemods.html
Big swings
At 07:42 PM 3/16/2005, Rasmus Lerdorf wrote:
William A. Rowe, Jr. wrote:
For anyone who wants to argue that this is a PHP-caused anomaly, note also
http://www.securityspace.com/s_survey/data/man.200501/apachemods.html
-10% followed by +11% the following month:
William A. Rowe, Jr. wrote:
Fascinating reading (see the bottom two tables of these pages:
http://www.securityspace.com/s_survey/data/man.200501/srvch.html?server=Apacherevision=Apache%2F1.3.33
http://www.securityspace.com/s_survey/data/man.200501/srvch.html?server=Apacherevision=Apache%2F2.0.52
At 05:48 AM 3/14/2005, Ben Laurie wrote:
William A. Rowe, Jr. wrote:
Fascinating reading (see the bottom two tables of these pages:
http://www.securityspace.com/s_survey/data/man.200501/srvch.html?server=Apacherevision=Apache%2F1.3.33
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
[...]
In that particular window (of a month) more folks took
Apache 2.0.x servers down in favor of 1.3.x servers,
than those who upgraded to 2.0.x from 1.3.x.
That may be explainable by someone familiar with the
hosteurope.de anomaly in the
On Feb 28, 2005, at 1:17 PM, Paul A. Houle wrote:
Honestly, I don't see a huge advantage in going to worker. On Linux
performance is about the same as prefork, although I haven't done
benchmarking on Solaris.
Under low-load conditions prefork often out-performs worker. Under
high-concurrency
Hi. Thanks for this. I've been tied up with a couple of things, so
please pardon the delay.
As far as this goes, Erik is correct, to a point!-) Just for tightness,
I want to make this as clear as mud!-)
To my read, and this meshes with others, SAML is open. RSA
Jess Holle said:
The use cases are:
1. multiple organizations, each with their own LDAP wish to allow
their personnel into a common site -- each has its own, separately
administered LDAP
2. a single organization has a read-only internal LDAP and a writable
LDAP for
Jess Holle said:
There have been enough instabilities and other issues in the LDAP
modules to date, but I would think this is the first big *feature* to
consider once these modules are fairly stable.
The LDAP stuff is now just about stable, so if you need it, now is the
time :)
I still think
Graham Leggett wrote:
Jess Holle said:
There have been enough instabilities and other issues in the LDAP
modules to date, but I would think this is the first big *feature* to
consider once these modules are fairly stable.
The LDAP stuff is now just about stable, so if you need it, now is
Jess Holle said:
I've not had a chance to try the LDAP connection timeout patch, but my
biggest remaining issue (besides the multiple-LDAP enhancement) is that
of firewall treatment. If there is a firewall between Apache and LDAP
(quite common) and if this firewall drops idle connections
Graham Leggett wrote:
Jess Holle said:
I've not had a chance to try the LDAP connection timeout patch, but my
biggest remaining issue (besides the multiple-LDAP enhancement) is that
of firewall treatment. If there is a firewall between Apache and LDAP
(quite common) and if this firewall drops
On Tue, 1 Mar 2005 16:18:17 +0200 (SAST), Graham Leggett
[EMAIL PROTECTED] wrote:
The trouble with the authentication problem is that the credentials used
for authentication are often used for way more than just finding out
whether a user has access. That said, this is definitely a very useful
Dependancy on third party modules still prevents us from upgrading from
1.3 to 2.0 or at least makes the the drawbacks of upgrading more
than the benefits That's the main holdup for us.
For instance, mod_perl (and a few custom scripts that use the API
extensively), mod_php (all those
Quoting Joe Schaefer [EMAIL PROTECTED]:
Its an httpd subproject. Basically its a server-side form-parsing
library with a 2.x apache module designed around the input filter API.
Writing a form based auth handler with apreq should be pretty easy.
For instance (shameless self-promotion):
On Tue, Mar 01, 2005 at 12:02:11AM -0600, William A. Rowe, Jr. wrote:
At 03:17 PM 2/28/2005, Paul A. Houle wrote:
On Mon, 28 Feb 2005 21:09:55 +, Wayne S. Frazee [EMAIL PROTECTED]
wrote:
We've got production instances of Apache 2 running on Linux and Solaris,
all of which are
William A. Rowe, Jr. wrote:
At 03:17 PM 2/28/2005, Paul A. Houle wrote:
On Mon, 28 Feb 2005 21:09:55 +, Wayne S. Frazee [EMAIL PROTECTED]
wrote:
Oh boy - you don't know *what* you are missing :) Threads on
Linux barely differ from distinct processes, while on Solaris
they are truly
Justin Erenkrantz wrote:
--On Monday, February 28, 2005 6:24 PM -0500 Jeffrey Burgoyne
I believe 255 concurrent clients is really low now-a-days for high-end
production servers.
It's when you start to get into several thousand concurrent connections
that I've found that the memory model of
But how many people really need 10,000+ concurrent connections?
Obviously CNN does. I'll make a bet Amazon does. Lets add ebay. Those are
power users.
The web site I manage does about 5 million hits per day (not including
graphics, style sheets, etc which are served by a different server), 80%
Paul A Houle said:
I think of all the features that web site authors and developers
need that still don't exist in mainstream web servers; part of this
is in the area of content management and another major are is
authentication -- pretty much any serious interactive web site needs
a
Graham Leggett wrote:
Paul A Houle said:
I think of all the features that web site authors and developers
need that still don't exist in mainstream web servers; part of this
is in the area of content management and another major are is
authentication -- pretty much any serious interactive
Graham Leggett [EMAIL PROTECTED] writes:
[...]
Something like an auth module that can do form based auth, in
addition to basic and digest etc would probably be very useful.
apreq does that.
--
Joe Schaefer
Joe Schaefer said:
Something like an auth module that can do form based auth, in
addition to basic and digest etc would probably be very useful.
apreq does that.
What is apreq?
Regards,
Graham
--
Jess Holle said:
Also a module (for Apache 2, not 1.3) that could use multiple LDAP
repositories -- and not for failover, but for separate user communities
-- all for a single resource/directory would be *very* helpful.
Can mod_authnz_ldap not do this?
Right now, you have to use arcane LDAP
Just a pointer to something that is gaining a bit of ground in various
circles:
http://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-
overview-2.0-draft-03.pdf
found at
http://www.oasis-open.org/committees/documents.php?wg_abbrev=security
This is about SAML, a vocabulary for
Graham Leggett [EMAIL PROTECTED] writes:
Joe Schaefer said:
Something like an auth module that can do form based auth, in
addition to basic and digest etc would probably be very useful.
apreq does that.
What is apreq?
Its an httpd subproject. Basically its a server-side form-parsing
Graham Leggett wrote:
Jess Holle said:
Also a module (for Apache 2, not 1.3) that could use multiple LDAP
repositories -- and not for failover, but for separate user communities
-- all for a single resource/directory would be *very* helpful.
Can mod_authnz_ldap not do
On 01.03.2005, at 15:52, Sean Mehan wrote:
Just a pointer to something that is gaining a bit of ground in various
circles:
http://www.oasis-open.org/committees/download.php/11511/sstc-saml-
tech-overview-2.0-draft-03.pdf
found at
On 01.03.2005, at 15:18, Graham Leggett wrote:
Paul A Houle said:
I think of all the features that web site authors and developers
need that still don't exist in mainstream web servers; part of this
is in the area of content management and another major are is
authentication -- pretty much
Jess Holle writes:
The use cases are:
1. multiple organizations, each with their own LDAP wish to allow
their personnel into a common site -- each has its own, separately
administered LDAP
2. a single organization has a read-only internal LDAP and a writable
LDAP for external
Wayne S. Frazee wrote:
Jess Holle writes:
The use cases are:
1. multiple organizations, each with their own LDAP wish to allow
their personnel into a common site -- each has its own, separately
administered LDAP
2. a single organization has a read-only internal LDAP and a writable
Fascinating reading (see the bottom two tables of these pages:
http://www.securityspace.com/s_survey/data/man.200501/srvch.html?server=Apacherevision=Apache%2F1.3.33
http://www.securityspace.com/s_survey/data/man.200501/srvch.html?server=Apacherevision=Apache%2F2.0.52
What is notable is that
William A. Rowe, Jr. writes:
I'd argue the opposite, we aren't refining 2.x sufficiently for folks to garner an advantage over using 1.3. It simply isn't more effective for them to use 2.0 (having tried both.)
William, I would have to agree. Honestly, I have personally seen the
business
On Mon, 28 Feb 2005 21:09:55 +, Wayne S. Frazee [EMAIL PROTECTED]
wrote:
A move to 2.0 or 2.1 will take place gradually over time, I think, once
PHP can be used with some expectation of stability on a
non-prefork-MPM. Note: I am not insinuating PHP is not thread safe, but
rather many
Paul A. Houle writes:
On Mon, 28 Feb 2005 21:09:55 +, Wayne S. Frazee [EMAIL PROTECTED]
wrote:
A move to 2.0 or 2.1 will take place gradually over time, I think, once
PHP can be used with some expectation of stability on a non-prefork-MPM.
Note: I am not insinuating PHP is not
Just one week ago I made the switch to 2.0 from 1.3.
I have to admit, the reasons were not overly convincing from a technical
perspective. The reasons we changed were :
1. Some know nothing consultant chided us in a erport for not upgrading to
the latest apache release, therefore strictly a
Jeffrey Burgoyne
Chief Technology Architect
KCSI Keenuh Consulting Services Inc
[EMAIL PROTECTED]
On Mon, 28 Feb 2005, Wayne S. Frazee wrote:
Paul A. Houle writes:
Correct me if I am wrong, but I have seen much that would purport the worker
MPM to deliever gains in terms of capacity
On Mon, 28 Feb 2005 21:31:19 +, Wayne S. Frazee [EMAIL PROTECTED]
wrote:
Correct me if I am wrong, but I have seen much that would purport the
worker MPM to deliever gains in terms of capacity handling and
capacity-burst-handling as well as slimming down the resource footprint
of the
Jeffrey Burgoyne wrote:
Not trying to poo poo 2.0, I think it is great and required in the
marketplace. I always suspected adoption would be slow, especially from
the generic masses who use a stock out of the package installation. I've
seen nothing to convince me that will not be the case moving
Paul A. Houle writes:
On Mon, 28 Feb 2005 21:31:19 +, Wayne S. Frazee [EMAIL PROTECTED]
wrote:
Correct me if I am wrong, but I have seen much that would purport the
worker MPM to deliever gains in terms of capacity handling and
capacity-burst-handling as well as slimming down the
Graham Leggett wrote:
Jeffrey Burgoyne wrote:
Not trying to poo poo 2.0, I think it is great and required in the
marketplace. I always suspected adoption would be slow, especially from
the generic masses who use a stock out of the package installation. I've
seen nothing to convince me that will
--On Monday, February 28, 2005 2:10 PM -0800 Paul Querna
[EMAIL PROTECTED] wrote:
Sure, it would be nice if everyone upgraded, but I hack on Apache 2 for
myself. Other people using it is just a bonus.
+1. Exactly my feelings as well. -- justin
--On Monday, February 28, 2005 10:08 PM + Wayne S. Frazee
[EMAIL PROTECTED] wrote:
Core directives to definitively control the amount of memory, et al, that
Apache 2 uses would be a DEFINITE functional upgrade-driver for some
businesses and applications to upgrade to 2.0. Apache has
I can go even one step further. 255 servers, 2.5 Gig of ram, huge config
(200 virtuals hosts, 1500 redirect rules, 2000 rewrite rules, 300 proxy
rules) and I never go into swap using prefork.
Mind you, no PHP, and that helps significantly.
I'll max out on CPU long before memory is all
I would think that a lot of this has to do with distributions and what's
supported out there. When major hosting companies change distros (which is not
a decision taken ligthly), they want to make sure _everything_ works for their
clients. Given that all major Linux and other distros ship Apache 2
--On Monday, February 28, 2005 6:24 PM -0500 Jeffrey Burgoyne
[EMAIL PROTECTED] wrote:
I can go even one step further. 255 servers, 2.5 Gig of ram, huge config
(200 virtuals hosts, 1500 redirect rules, 2000 rewrite rules, 300 proxy
rules) and I never go into swap using prefork.
I believe 255
All true, but we are running a 100K (Canadian) blade center, and at 255
apaches per server and 10 blades, thats ~2500 concurrent users. You have
to have a pretty honking Sun box to manage that, certainly within the same
price range, and another 15K buys me 40% more power.
I have come to the
Jeffrey Burgoyne wrote:
All true, but we are running a 100K (Canadian) blade center, and at 255
apaches per server and 10 blades, thats ~2500 concurrent users. You have
to have a pretty honking Sun box to manage that, certainly within the same
price range, and another 15K buys me 40% more power.
At 03:09 PM 2/28/2005, Wayne S. Frazee wrote:
William A. Rowe, Jr. writes:
I'd argue the opposite, we aren't refining 2.x sufficiently for folks to
garner an advantage over using 1.3. It simply isn't more effective for them
to use 2.0 (having tried both.)
Further, I would submit that there
At 03:17 PM 2/28/2005, Paul A. Houle wrote:
On Mon, 28 Feb 2005 21:09:55 +, Wayne S. Frazee [EMAIL PROTECTED]
wrote:
We've got production instances of Apache 2 running on Linux and Solaris,
all of which are running PHP on prefork.
Honestly, I don't see a huge advantage in going to
William A. Rowe, Jr. wrote:
At 03:17 PM 2/28/2005, Paul A. Houle wrote:
On Mon, 28 Feb 2005 21:09:55 +, Wayne S. Frazee [EMAIL PROTECTED]
wrote:
We've got production instances of Apache 2 running on Linux and Solaris,
all of which are running PHP on prefork.
Honestly, I don't see a
51 matches
Mail list logo
