Slashdot Mirror


Apache Cookbook

honestpuck writes "While Apache is possibly the most popular and ubiquitous open source project it is certainly not the most simple. One module alone, mod_rewrite, causes me almost more problems and regex wrestling matches than all other products combined. The 'httpd.conf' file is a long and critical one. In these circumstances the Apache Cookbook from O'Reilly might be a godsend. It is certainly a well-written, well-researched volume. Ken Coar has spent many years working on Apache and Rich Bowen has long laboured on the Apache documentation. They both know their stuff -- and if this is an example, both know how to write." Read on for the rest of honestpuck's review. Apache Cookbook author Ken Coar & Rich Bowen pages 223 publisher O'Reilly rating 8 reviewer Tony Williams ISBN 0596001916 summary A broad range of Apache admin topics covered well

The book has twelve chapters, covering everything from installation and adding modules through to proxies and performance. The chapter on security is the largest, it covers the topics well. By contrast I thought the chapter 'Aliases, Redirection and Rewriting' too short and could have benefited from some more 'recipes', but that may be due to my own bias - mod_rewrite is not an easy topic, and as I've said it causes me a great deal of grief.

It is laid out in a similar way to the Perl Cookbook: each recipe has a 'Problem' section followed by a 'Solution' and then 'Discussion.' In almost all the 'recipes' the 'Discussion' is longer than the 'Solution,' and I often found it far more useful and informative than the problem and its solution.

The Apache Cookbook covers almost all aspects and all parts of the learning curve for Apache. That will either be a strength or a weakness of this volume for you; with such a large and complex piece of software as Apache a single book cannot hope to cover it in a great deal of depth. For me this book was not really a cookbook, more a good source of well documented examples from which to create my own recipes,

My biggest problem reviewing a book like this is that after several years building and configuring Apache (even on an infrequent basis) quite a lot of this volume seems simple. You may also find it the same if you are the sort of person who is not afraid to pore over the documentation, get your hands dirty and make a few mistakes. If you like some hand holding and are just starting with Apache you may benefit from all of it.

That's not to say that I didn't personally find large chunks of this volume useful. Certainly I've gone over several of the recipes and their excellent explanatory text to shed some light on previously dark corners of Apache, particularly as the authors cover both Apache 1.3 and 2.0.

O'Reilly have the usual web page with a Table of Contents and example chapter. The example chapter, on error handling is well chosen as it is typical of the others and useful but not the most useful chapter.

I have recently been thinking that tech books fall into various sorts and there is one sort I'd call 'library books' - books you may not need to own, but will want to read every so often and would be good to have in your local or company library. Apache Cookbook is one of these, a book I'd recommend everyone coming to grips with Apache has close to hand, but it is not going to be constantly on your desk in the same way that Perl Cookbook might be for Perl programmers: to start off with, it's half the size and doesn't cover nearly as many topics. This one falls short of essential due to it's concentration on breadth. rather than depth. So my recommendation for this book is not that all Apache administrators should buy it, but you should have a copy close at hand.

You can purchase the Apache Cookbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

6 of 172 comments (clear)

  1. Apache is damned good. by chadw17 · · Score: 3, Insightful

    Only big problem I've ever encountered, and this may seem n00bish, but routing multiple domains to a single machine involved some heavy httpd.conf editing. Almost made me wish for a GUI, but what you learn from error and mistake, (over and over again) helps in the end.

  2. Sounds great. by ActionPlant · · Score: 5, Insightful

    This is a godsend to those of us who are just starting out. Sure there is a lot of decent online documentation, but that requires running back and forth from machine to machine and taking a lot of notes.

    I'll definitely be picking this up.

    Damon,

    --
    http://actionPlant.com
  3. Re:Problem. by RexRuther · · Score: 2, Insightful

    But what if all I want to do is publish a web page?

    --
    -"The early bird catches the worm, but the late bird sleeps the most"
  4. Re:True That! by DAldredge · · Score: 2, Insightful

    Why do you say perl is ugly? It depends on the person writing it. I have seen some horrible PHP code in my lifetime, just like I have seen bad code in any number of languages.

  5. Good thing with apache by arvindn · · Score: 2, Insightful

    There are lots of examples of open source programs which are very complex and powerful and have a steep learning curve, forcing users to read lots of documentation before being able to do anything useful with them (random examples: mutt, mplayer, vi/emacs, sendmail). That's not the case with apache. A n00b who just wants to serve a few simple static pages can simply copy the files to www or public_html directory and they're done. You need to deal with the complexity only if you want to. I guess that's one of the reasons why its so popular.

  6. Re:Use Apache! by KlomDark · · Score: 3, Insightful

    Uh, no. You're buying into the Microsoft delusion that the web server itself should support application level functionality.

    The web server should always be simply a front-end to the application server. The web server functionality built into the application servers is very limiting. Let the web server be the web server, let the app server be the app server - Don't mix them up.

    Put in Apache to handle the normal requests, with the appropriate Apache module to connect to the app server and pass the app server code requests to the app server (via the connector module) to be processed there, while leaving Apache free to serve normal web content.

    This gives you the best of both worlds in performance and configurability. Any other way is buying into some marketing idiot's dream.