Slashdot Mirror
Professional Apache 2.0
Although Apache changed a great deal in its version 2.0, it is a credit to the Apache folk that the config files and command line options have basically remained the same for sys admins. For this reason, the book seems to include a lot of material (CGI security, building, core modules) from the original book. However, a closer look reveals many changes. Almost every chapter includes a discussion about how features differ in both versions of Apache. The book does a good job of giving an overview of Apache's architectural changes and how the use of multi-processing modules (MPM) allow the admin to choose an optimal implementation of apache. This edition, noticeably bigger than the previous one, contains many more examples of how one can extend apache functionality (configuring for binary distribution, setting up virtual interfaces, load sharing). Many sections have been expanded. The discussion of security and SSL is more detailed, yet more succinct; so is the section on content negotiation, (which is twice as long as the previous book), doing proxy server configurations, rsync and benchmarking performance. The discussion on hardening the server was great and up-to-date, although I wish the book spent more time discussing on patching and upgrading.
What is new to the book? We find a longer discussion of graphic administration tools for Windows and Unix, including webmin (which actually I wanted more of). We also have discussions of newer modules such as mod_ruby, mod_python, mod_dav as well as a brief description on how to install tomcat alongside apache. The discussion of mod_dav was especially helpful and interesting to me (and I was especially glad that the author acknowledged the Subversion DAV module, something which is bound to become more important). The php stuff hasn't changed much (although at the time the book was published, 2.0 compatibility with PHP was still an iffy proposition). The book's discussion of mod_perl isn't significantly different, although it does point out migration issues and some additional features.
Generally, the book is clearly written and contains enough examples to find any configuration you want. A few parts required rereading (especially the part about proxies and proxypasses), and occasionally I needed a better explanation of what the example code was supposed to do.
No book can be everything for everybody, and nobody can accuse the book of not having enough content (it is after all more than 700 pages!). I found myself wishing for other things. The book briefly discussed 2.0's support for ipv6, but I longed for a fuller explanation and a more detailed example (Fortunately, I had seen a good ipv6 tutorial on Linux Journal ). Also, I would have liked more information about other web application servers (like zope that Apache sometimes coexists with, content frameworks (such as cocoon) and other goodies produced by the Apache Foundation. The author might legitimately feel that such subjects lie outside the book's scope, but such topics are becoming more important.
In summary: for newbies who are looking for a guide to start with: this is the definitive book to read. It's definitive and a little imposing, but it is well written and logically arranged.
For people already familiar with Apache 1.3 but looking for more depth about ipv6, php, content frameworks or Tomcat, it might be better to read books on those specific subjects instead of this one. Indeed, Wrox will soon be coming out with a book specifically on Apache and Tomcat.
For experienced system administrators, the material in this book may not be terribly new, but they will still appreciate the variety of configuration examples for managing large numbers of virtual hosts and the convenience of having documentation of the 1.3/2.0 differences at their fingertips.
You can purchase Professional Apache 2.0 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
You know, it's an amazing myth perpetuated by O'Reilly's publishing strategy that only people who create products are qualified to write about them.
Someone who administers Apache servers for a living might actually be in a better position to tell admins what they need to know than the person who implemented some cool feature and wants everyone to know about it.
Okay, I tried to resist, but I've got to answer this ...
I really, really hate the "academia vs. real world" dichotomy that a lot of techies try to set up. Yes, business programming problems are different from classroom programming problems. Yes, academics develop a lot of ideas about programming that seem brilliant in a theoretical context but prove pretty much impossible to implement in production shops. Yes, there are shitty CS profs out there who don't keep up on the latest developments in the field and fill their students' heads with ideas that are outdated, impractical, or just plain wrong.
But. There is at least as much of a problem with "real-world" programmers and admins, many of whom are mostly self-taught and therefore have no idea where the gaps in their knowledge are, who really ought to pay more attention to academic computer science. A lot of the code I have to work with as a DBA and Web developer is, frankly, astonishingly bad. Yeah, it gets the job done, but the fact is that it would get it done a lot better if it were written by people who had some exposure to the theoretical underpinnings of CS like set theory and algorithm analysis -- and, just as importantly, to the people who develop those underpinnings.
The vast majority of the whiz-bang technologies that make computers as useful as they are came out of university labs -- not corporate R&D shops that are all "D" and no "R," not teenage genius hackers in their basements, and sure as hell not people who think that academia and the real world are somehow two separate domains, never the twain shall meet.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
To the moderator: do not jump to moderate as flamebait until you have read it till the end please. As a person who have worked both in Academia (in more than one country) and in Corp (once again in more than one country) I have to say that you are deeply mistaken.
Excuse me for the engineering language but current academic CS is mostly full of shit. It is mostly a collection of people who excel in vendor and sponsor nasoanal relationships. Especially the latter.
What you describe is not CS. It is good old MATH. And what makes most programmers write shitty code is lack of solid background in mathematics. The subjects you have mentioned like set theory are just a scratch on surface. Game theory, optimisation, numerical methods, to be continued ad naseum.
I will also disagree with some of your conclusions on selftaught as synonimous with lacking. A selftaught programmer coming from a mathematical, physical or even chemical background is often a better programmer then the surrogate CS engineers printed in some countries which have cut down their math requirements for CS to almost nothing. And which do not have any of the subjects mentioned in their BSc programmes for most colleges.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/