Apache 2.0 Goes Beta 20
Great news from the Apache Conference. A new version of Apache 2.0 has been released as a beta. You can find more information in their announcement. In other news according to Roy Fieldling's talk on the state of Apache, as of their next fiscal year individuals should be able to make tax deductible contributions to the Apache Foundation.
Re:mod_perl 2.0? (Score:1)
There is some info on the modperl-dev mailing list [theaimsgroup.com], Hope this helps. There is probably a lot more.
Re:Upgrading from 1.3.x & preserving configuration (Score:1)
Upgrading to Apache 1.3.19 and mod_ssl is the way to go for now, unless you feel the need to pay for Stronghold.
There really isn't any easy way to merge the configuration file to 1.3.19. My best suggestion is to set up the new server running on an alternate port (like 8080/8443) and move the configuration over bit by bit, testing as you go.
Good luck!
PHP (Score:2)
Re:PHP (Score:2)
Is XSLT worth it? (Score:2)
XSL tags and function are so verbose and hard to read compared to using xmltree() in php and then using foreach statements.
In all honesty exactly what does xslt do better then php?
Re:Upgrading from 1.3.x & preserving configuration (Score:2)
As for the instability of the 2.x series, yeah, I know it isn't anything reliable yet, and I'm not planning to move to it yet. But right now we've got...
...and if it isn't a total headache to upgrade to something approaching 1.3.19 then I might do it at some point. But again, Things Work so I don't wanna Fuck With It.
Sooner or later though a slow week will come along & I'll probably do it. I was just hoping to hear something about a utility to update configuration files. Guess not. Oh well....
Re:Upgrading from 1.3.x & preserving configuration (Score:2)
Slackers. [useit.com]
:)
Anyway, as for the extent of the patches, I'm not entirely sure. It was built quite a while before I came to the company, and the modules that are running are all statically built in. Much to my annoyance, dynamic linking was disabled in the built version, meaning that the only way to add things like mod_speling (which would eliminate about 90% of our 404 errors, particularly people looking for INDEX.HTML etc & Apache being too case-sensitive for its own good) is by one way or the other rebuilding the server from scratch. Dammit.
Otherwise, the most exotic things we're doing seem to be Raven (which you make sound like it isn't very exotic at all) and NetSaint, which I can handle just fine. When time allows it, I'll start migrating things over to a new version I guess....
Upgrading from 1.3.x & preserving configuration (Score:3)
I've inherited & since further adapted the installation that has been running at work, and I don't relish the idea of having to merge together the current httpd.conf file & various binaries into those of a newer version. If nothing else, all the various redirects, aliases, raven-ssl settings, etc that we're currently using would, I assume, be trampled by a stock upgrade. Further, I don't want to just maintain the current httpd.conf file on top of an upgraded installation, because it doesn't make any mention of some of the newer features that would become available and that I'd like to take advantage of.
Are there tools out there to merge in old settings with a new installation? I don't like the idea of mucking around with diff scripts to do this, but to date I haven't been able to think of any better alternatives. Can someone help?
Re:Beta for alpha testing? - For ALPHAs (Score:1)
Beta for alpha testing? (Score:5)
What's the plan with XML? (Score:1)
Does anyone know what the plan with XML is? I noticed this new release has a `filter' system which you could probably use to support XML/XSLT stylesheets. Has anyone tried this? Does Apache has a `bigger plan'?
Re:PHP (Score:2)
Ideally PHP would be expanded first, then the appropriate XML transformation applied. PHP's current support for XML is a nice tool, but doesn't help move your site toward XML.
As for performance, I see no reason why an effecient XSLT engine can't be written. This is exactly what XML is all about--writing content once, and formatting to taste.. on the fly. I believe confirming this is possible is one of the goals of Apache's XML project. What I'm wondering is what kind of progress have they been making, and when will it be imbedded in apache itself?
After my first post, I hit freshmeat and found an apache xml module. My impression is it's ``not quite there yet'', but it's encouraging.
New features with Apache 2.0 (Score:2)
Unix Threading
On Unix systems with POSIX threads support, Apache can now run in a hybrid multiprocess, multithreaded mode. This should improve scalability.
New Build System
The build system has been rewritten from scratch to be based on autoconf and libtool. This makes Apache's configuration system more similar to that of other packages.
Multiprotocol Support
Apache now has some of the infrastructure in place to support serving multiple protocols. mod_echo has been written as an example.
Better support for non-Unix platforms
Apache 2.0 is faster and more stable on non-Unix platforms such as BeOS, OS/2, and Windows. With the introduction of platform-specific multi-processing modules (MPMs) and the Apache Portable Runtime (APR), these platforms are now implemented in their native API, avoiding the often buggy and poorly performing POSIX-emulation layers.
New Apache API
The API for modules has changed significantly for 2.0. Many of the module-ordering problems from 1.3 should be gone. 2.0 does much of this automatically, and module ordering is now done per-hook to allow more flexibility.
Also, new calls have been added that provide additional module capabilities without patching the core Apache server.
IPv6 Support
On systems where IPv6 is supported by the underlying Apache Portable Runtime library, Apache gets IPv6 listening sockets by default. Additionally, the Listen, NameVirtualHost, and directives support IPv6 numeric address strings (e.g., "Listen [fe80::1]:8080").
Filtering
Apache modules may now be written as filters which act on the stream of content as it is delivered to or from the server. This allows, for example, the output of CGI scripts to be parsed for Server Side Include directive by mod_include.
Module Enhancements:
mod_auth_db
Now supports Berkely DB 3.0
mod_auth_digest
Includes additional support for session caching across processes using shared memory.
mod_charset_lite
New module in Apache 2.0. This experimental module allows for character set translation or recoding.
mod_dav
New module in Apache 2.0. This module implements the HTTP Distributed Authoring and Versioning (DAV) specification for posting and maintaining web content.
mod_file_cache
New module in Apache 2.0. This module includes the functionality of mod_mmap_static in Apache 1.3, plus adds further caching abilities.
You're tired of Slashdot ads? Get junkbuster [junkbusters.com] now!
Re:mod_perl 2.0? (Score:1)
Re:mod_perl 2.0? (Score:1)
Got it working, thanks for the hint.
Server Version: Apache/2.0.16 (Unix) mod_perl/1.99_01-dev Perl/v5.6.0
I had to recompile Perl to use ithreads, but the stuff works trivially.
From reading the docs, it looks like the architecture changed a lot, but the new design should avoid some of the issues with a "fat" apache/mod_perl memory footprint.
mod_perl 2.0? (Score:2)
It's not in the main distribution, and i couldn't find any info on the mod_perl mailing list archives.
That's what i'd like to try out.
Re:Upgrading from 1.3.x & preserving configuration (Score:2)
It's a lot easier to keep up to date now, mod_ssl gets updated within a day or two of a new apache release.
If you are building from source, you just have to figure out how you want to build apache, and get those
As for your httpd.conf file, it should be the same, except for replacing all the ravenssl stuff with mod_ssl. There will be some pain getting it right, but it shouldn't be too hard.
Yay! More options! (Score:2)
Re:Upgrading from 1.3.x & preserving configuration (Score:1)
Can anyone provide some rough advice on how it might be best to upgrade from an "old" & moderately customized version of Apache to the 2.x series, or even the recent 1.3.x series?
This depends on the extent of your patches. Some things have changed in the architecture of 2.0, so your patches may not apply or even be necessary. The module API has also changed, so you'll have to re-do your own modules.
RavenSSL is not available for 2.0 yet. As another poster says, the open source TLS implementation(s) is/are not finished either, so if your site depends on SSL you may want to keep 1.3 around for a while longer.
Of course, you don't have to move your production server over immediately. Start running 2.0 on your staging box. If you don't have one, get one. Of course this staging box doesn't have to be an identical copy of your web server: it can be a white box linux PC or even your desktop system since Apache runs on anything but the tea kettle. When you are satisfied with a) functionality, b) stability and c) performance, you move the web server over. You can even stage that: run 2.0 on port 8080 initially while you build the system. When you're done, simply flip ports between 1.3 and 2.0.
Re:Upgrading from 1.3.x & preserving configuration (Score:1)
Whaddya mean, Apache doesn't run on a tea kettle?
Slackers [useit.com].
This is absolutely hilarious. If it actually runs Apache I'm going to have to get one for the office.
Otherwise, the most exotic things we're doing seem to be Raven (which you make sound like it isn't very exotic at all) and NetSaint, which I can handle just fine.
Raven is an SSL plugin. I work for the company that makes it [covalent.net] (but I don't speak for them, #include stddisclaimer.h), so that's probably why it's not very exotic to me. Raven is a closed source module. Otherwise, if you have the source code of your current version, you can do a diff against the present code base to see what the differences are. If you're really in the dark, you should approach the web server like a black box and (re)define a set of functional requirements, collect and integrate the software and keep record of what you have been doing on file. That's a sound business practice anyway: what if your present webserver irrepairably crashes?
Oh, have you considered making soft links for the most frequently occuring 404's with the misspel(l)ed names? This may be a bit more maintenance intensive but you don't need mod_speling.