Apache 2.0.40 Released 35
cliffwoolley writes "On August 7, the Apache Software Foundation was notified of a significant vulnerability that affects the Win32, OS/2, and Netware ports of Apache 2.0. It has the potential to allow an attacker to inflict serious damage to a server and/or reveal sensitive data on those platforms. To fix this vulnerability in addition to a number of cross-platform issues (a pair of path exposures and a number of bugs), Apache 2.0.40 has been released. It is considered the best currently available version of Apache, and all users are urged to upgrade."
PHP? (Score:5, Informative)
Re:PHP? (Score:1)
-jim (who found the cgi/cgid path exposure in 2.0.39)
Re:PHP? (Score:4, Interesting)
Re:PHP? (Score:3, Insightful)
And then there's mod_perl, which is also apparently in beta for Apache 2. I'd upgrade if I could reliably run Slashcode under that.
Re:PHP? (Score:2, Informative)
Re:PHP? (Score:1)
Not much.
Re:PHP? (Score:1)
As soon as PHP4 and Apache 2 play nicely (it wasn't setting cookies correctly on some browers for some reason??) and Zend (et al) solutions work on it we can't use it, although we are REALLY looking forward to it (the hybrid thread model is neat-oh).
Re:PHP? (Score:2)
PHP 4.3.0 is essential, because the new features of Zeus 2.0 (try/catch, etc, etc) I use heavily. However I have had all kinds of problems getting PHP to work with Apache2, since 2.0.29 seemingly broke PHP...
Re:PHP? (Score:1)
Re:Apache and security (Score:3, Insightful)
When will you stop bitching and join the Apache devel team to help make it secure? When will you submit a non-blocking I/O patch to the Apache codebase?
If you don't like the direction they are going, either don't use it or join the devel team. There's no need to bitch and moan about it like it intimately affects your life.
Apache is NOT the fastest out there...but it is the most configurable (PHP, Perl, etc) and the best all-around webserver there is. Many of us think that the Apache team has done great work and we apprieciate every minute of it.
Re:Apache and security (Score:4, Informative)
When will you stop bitching and join the Apache devel team to help make it secure? When will you submit a non-blocking I/O patch to the Apache codebase?
Apache can't be made secure for the same reasons that BIND and Sendmail can't be made secure. It needs to be completely rewritten using secure coding practices. You can't just keep fixing security bugs and hope you found them all.
If you knew anything about Apache's design, then you would know that it's impossible to just add non blocking I/O. The entire server would have to be redesigned. If you read the Apache development list, then you will see that this is never going to happen. The developers don't care. They seem convinced that it is too much work and get upset when anyone mentions the idea of non blocking I/O. There are more than technical issues that need to be solved before Apache can become a better server.
If you don't like the direction they are going, either don't use it or join the devel team. There's no need to bitch and moan about it like it intimately affects your life.
So I'm no longer allowed to give my opinion? I thought that was the purpose of this comment forum.
Apache is NOT the fastest out there...but it is the most configurable (PHP, Perl, etc) and the best all-around webserver there is. Many of us think that the Apache team has done great work and we apprieciate every minute of it.
Yes, that's exactly my point. It's the best we have and no one seems to care that it could be ten times better. And no, it's not just a matter of a few patches. Apache's design is fundamentally flawed.Re:Apache and security (Score:1, Interesting)
Re:Apache and security (Score:2, Troll)
Many programs have yet to be written. Perhaps this is one of them. Maybe you'd like to write it? I think you'll be much happier if you stop expecting people to do things for you.
Re:Apache and security (Score:1)
Change. This is what OpenSource is all about.
Granted the Apache group is large and the voice of one may not be immediately heard but it only takes the voice of one to start things moving.
By not bitching and instead finding a way to change things is what makes us different from them.
For them "There is no choice, there is only M$." (quote found on the web) but for us it is "Find a way or make one." (personal life philosophy)
Cheers
Re:Apache and security (Score:4, Informative)
Both are multithreaded web servers, which are very good at producing dynamic content.
They have a very nice macro language built in (RXML [roxen.com]) and support scripts written in the language Pike [ida.liu.se] (which both servers are written in as well). Both also support embedded perl scripts, as well as java servlets, and fastcgi scripts. It also has very good database support, and support for dynamic image generation.
I haven't used Caudium myself - it is a fork [caudium.net] of the Roxen 1.3 codebase, and I had already started using the new 2.x features before the fork happened. It is GPLed, and is available here [caudium.net]
Roxen is available in two forms, a free GPLed version (available here [roxen.com]) and a commercial version which includes content management features (Demo available here [roxen.com]).
The new versions of Roxen are bundled with a MySQL install which the server uses for storing configuration data, caching generated images and pike/rxml pcode, and for storing internally managed user databases. It also works well with PostgreSQL as an external database.
Php support in roxen is a little tricky. Recent versions of PHP can be compiled into a module that can be merged into pike, allowing both Roxen and Caudium to execute PHP scripts inside of the multithreaded main process. This is still buggy under Roxen, but I understand that it works well under Caudium. Personally, I compiled php as a fastcgi, and used Roxen's fastcgi module.
Re:Apache and security (Score:1)
Re:Apache and security (Score:2)
Re:Apache and security (Score:1)
Re:Apache and security (Score:1)
support scripts written in the language Pike (which both servers are written in as well).
and Pike, according to the Caudium website, is interpreted.
What's the point of having non-blocking I/O if you're going to run via an interpreter? Does it really have respectible performance?
Re:Apache and security (Score:1)
Re:Apache and security (Score:3, Interesting)
OK, I'm not a Linux man: but I didn't think Linux actually supported proper asynchronous I/O. And the acryonym, for better or for worse, is still LAMP and not FAMP or SAMP (or even SAOP). (WISA, anyone? :-) ) Sure, you can pass a shed-load of sockets into a select() call but I can't see select()'s efficiency being even close to linear in set size.
Linux does not support the POSIX AIO interface with a standard kernel (SGI has an implementation available). The supported Linux method is realtime signals. While there is probably a good reason that they chose this non standard, Linux specific method (besides the "because we can"), I haven't seen anything documenting the reasoning.
Another method, /dev/epoll [xmailserver.org], is somewhat similar to Solaris' /dev/poll. It is more efficient and has (IMHO) a cleaner interface than the realtime signals. Hopefully this patch will make it into the mainstream kernel.
The following page is an excellent reference on I/O models: http://www.kegel.com/c10k.html [kegel.com]
And, yes, both select() and poll() both have scalability limits somewhere after a few thousand descriptors. However, a non blocking server using these will still be much more scalable than a multiprocess blocking server such as Apache. The overhead of that many processes will kill you.Re:Apache and security (Score:1)
Here [fredan.org] can you find some benchmarks that I have done. All test was made on kernel 2.4.18