Covalent's Version of Apache 2.0 To Drop Monday

kilaasi points out this CNET story about the planned release on Monday of Apache 2.0, "or at least the version that has proprietary extensions. Covalent sells the core of Apache and its own extensions which make it easier to adapt for specific areas and simpler to administer. Covalent is confident that the next generation Apache is mature and is ready for prime time. Covalent employs some of the core members of the Apache-development-team." XRayX adds a link to Covalent's press release, writing: "It's not clear when the Open Source Edition (or whatever) will come out and I didn't find anything at the official Apache Site." Update: 11/10 16:37 GMT by T : Note that the product name is Covalent Enterprise Ready Server; though it's based on Apache software, this is not Apache 2.0 per se. Thanks to Sascha Schumann of the ASF for the pointer.

Comments

Static PHP + scripts running as users

[chrysalis]

One of the most annoying thing in Apache 1.x is that when PHP is compiled in the server (not run through the CGI), all scripts are running as "www", "nobody", or whatever anonymous user your Apache daemon is running as.
There's no way to have PHP script run as different users (just like what suexec does for spawning CGI external progs) .
Sure, PHP has a so-called "safe-mode", but it's still not that secure, especially when it comes to creating files or acess shared memory pages.
I was told that Apache 2.0 had a mechanism that could make user switching for PHP scripts possible. Has anyone experimented with it?

Re:Static PHP + scripts running as users

[cehf2]

With any application running on a web server there is a trade off between performance and security. because the PHP module is running inside the core of the web server, it should be fairly fast, however if you want the ability to change what users the php scripts run as, your only option is to use CGI scripts. CGI by its very nature is *very* slow. This is due to the overhead of the fork/exec/load program.

You may also be able compile PHP as a FastCGI program, you could then run several external FastCGI's as different users and configure Apache to run the particular script with a particular FastCgi program. I have no idea how to do this with apache, as I use Zeus myself.

If Apache 2 does have a way to switch users for PHP scripts, it will not be secure. Under UNIX, once you have dropped your permissions you can never gain them again. The work around is to have 'real' and 'effective' users that programs run as. As long as you only change your efective user, you can re-gain permissions, but anything can regain permissions. You can also only change users when you are root. This would be a big security hole, in that if there was a buffer overflow attack root could trivially be optained by anyone.

security, performance, configurability - pick 2

At $1495 per CPU

[imrdkl]

This thing better weave with golden thread(s)

Re:At $1495 per CPU

[GC]

Yes quite, for those of you who just want to download Apache 2.0, compile it and have it running by the time you could have bought the package from Covalent, go here

Time warp?

[carm$y$]

From the press release:
SAN FRANCISCO -- November 12, 2001 -- In conjunction with the launch of Enterprise Ready Server, Covalent Technologies today announced a coalition of support for its new enterprise solution for the Apache Web server.

Is this a little bit confusing, or what? I mean, I had a meeting on Monday the 12th... well... which I don't recall yet. :)

Re:Apache has released 2.0 betas

[huftis]

It's not clear when the Open Source Edition (or whatever) will come out and I didn't find anything at the official Apache Site.

Apache Week has more information on this:

Those waiting since April for a new 2.0 beta will have to keep on waiting after another release candidate, 2.0.27, was abandoned this week when a bug was discovered while running the code on the live apache.org server. Some httpd processes were found to be stuck in infinite loops while reading POST requests; the bug was traced to the code handling request bodies. After fixes for this bug and a build problem on BSD/OS were checked in, the tree was tagged ready for a 2.0.28 release.

Re:Can threads really beat fork(2)?

[jilles]

Programming threads is just as hard as programming with processes on a conceptual level. The type of problems you encounter are the same.

However, process handling is potentially more expensive since processes have separate address spaces and require special mechanisms for communication between these address spaces. From the point of view of system resources and scalability you are better of with threads than with processes. Typically the amount of threads an OS can handle is much larger than the amount of processess it can handle. With multi processor systems becoming more prevalent, multithreaded systems are required to be able to use all the processors effectively and distribute the load evenly.

The primary reasone why you would want to use processes anyway is stability. When the mother process holding a bunch of threads dies, all its threads die too. If your application consists of 1 process and 1000 threads, a single thread can bring down the entire application. At the process level, you have the OS shielding each process' addressspace from the other processess so that gives you some level of protection against misbehaving processes. Running apache in multiple processes therefore gives you some protection, if one of the httpd processes dies, the other processes can take over and continue to handle requests.

The use of highlevel languages & APIs (e.g. Java and it's threading facilities) addresses these stability issues and makes it safer (not perfectly safe) to use threads. Java for instance offers memory management facilities that basically prevent such things as buffer overflows or illegal memory access. This largely removes the need for the kind of memory protection an OS offers for processes.

Apache 2.0 is specifically designed to be more scalable than the 1.3.x series. Threading is a key architectural change in this respect. Sadly it is not written in Java which unlike some people on slashdot believe is very capable of competing with lower level languages in this type of server applications. Presumably the apache developers are using a few well developed C APIs to provide some protection against stability issues.

Apache 2.0 is *not* out on Monday

[markcox]

Although the CNet article tells you otherwise, the open source verison of Apache 2.0 is not available on Monday, and as stated in Apache Week, is only just becoming stable enough for another beta release. Covalent are launching a commercial product that is based on Apache 2.0 but with proprietary extensions (the Apache license unlike the GPL allows this). IBM's httpd server has been based on a 2.0 beta for a number of months. Since Covalent say they've made it Enterprise Ready they must have cured the performance and stability problems, when these get contributed back to the main Apache 2.0 tree everyone wins.

Mark Cox, Red Hat