Forgot your password?
typodupeerror
Book Reviews Books Media

Apache Cookbook 2nd Edition 42

Posted by samzenpus
from the read-all-about-it dept.
stoolpigeon writes "The Apache web server has been the number one http server on the internet since 1996. It has also become an integral part of many open source and proprietary software systems. It runs on diverse hardware, in locations all over the globe, hosting sites large and small. In November of 2003 Ken Coar and Rich Bowen had their "Apache Cookbook" published by O'Reilly. The duo brought years of experience in working with and documenting the Apache server to the plate. Now, over 4 years later they have published the second edition. Four years is a long time, but it would be reasonable to ask if this new edition is worth purchasing, especially if one already owns the first edition." Read below for the rest of JR's review.
Apache Cookbook 2nd Edition
author Ken Coar and Rich Bowen
pages 285
publisher O'Reilly Media, Inc.
rating 8
reviewer JR Peck
ISBN 0-596-52994-5
summary Solutions and examples for Apache Administrators
The answer is of course, it depends. After I read the new edition I sat down with a copy of the first edition so that I could compare the two. The most obvious and easily noticed difference is that the second edition is larger. Including the index, the second edition is 51 pages longer. This does not mean that they just tacked on 51 more pages of material. A small amount of material was dropped from the first, sections were added to almost every chapter in the second, and an entirely new chapter was added to the second. I think that this bodes well for the new edition as it indicates that the authors did not just slap a few new pages in place to cover some new features, or do a quick search and replace on version numbers. There is a decent amount of repeated material, but only where there have been no changes needed.

The authors state that every recipe comes from real world needs, either working problems on their own or helping others. I am sure that this approach is what drove many of the changes. Sections that are no longer applicable or don't seem to come up as often could be dropped to make room for new issues, or issues that have come up with a higher frequency. The new content as I mentioned is spread out throughout the book. For example, the first chapter "Installation" originally had 7 sections and now has 13. This is due to additional sections on things like installing on Debian based machines, which version of Apache to use, and more sections on downloading and then installing Apache from source.

The new chapter is "Directory Listings". There are 20 sections or 'recipes' that deal with displaying directory/folder listings and modifying the same. Only four chapters do not add more sections in the second edition. Of those only two still contain the same recipes, the other two have had some dropped and others added. Of those two, I checked the various problem solutions and found that while there were many similarities, links to documentation and resources had been updated as well as fixing the recipe if needed. This book has been very thoroughly overhauled.

While the information given is often new, the format, layout and writing are very consistent with the first edition. This means the strengths of the first book carry over as well as some of the weaknesses. The issues I had with the book are that much of it will seem rather simple or basic to the admin who likes to dig into documentation, or is already familiar with installing and managing software. This may be a great thing for the novice or someone trying to install Apache on a platform they don't normally use. (Whether that is Linux or Windows. The Linux install instructions are very brief; the Windows instructions include screen shots and take up more room but cover the whole process. Might be handy for anyone who must install Apache on Windows, but unfamiliar with the OS.) But for the experienced Apache or System Admin it may feel unnecessarily simplistic at times. For example, a new section from the first chapter has added how to download the source along with installing from the source.

Another thing I found awkward is when problems were presented with no solution. I guess the question has come up enough for the authors to feel it deserved being addressed in the book, but in both editions there are times when the solution is literally, "No solution is available with standard Apache features." The authors do take the time to explain why this is so, and the issues involved, but it felt odd nonetheless. The discussion and "See Also" sections will probably be helpful, but this just brought to the forefront that often administration of software is a lot more than just recipes in a cook-book.

I think it is safe to say that if you have or have read the first edition and are still using it, it may be worth your time to check out the full table of contents on the second edition. There may be some new things here that could really come in handy and make it worth picking up this new volume. If you didn't like the first edition, I doubt you will be too crazy about the new one. If you haven't been exposed to the first edition but are new to Apache, or find yourself struggling with Apache, this may really be a great help. For the experienced Apache admin, I would again recommend checking out the table of contents. It shouldn't be too difficult to see if there is something worthwhile here. With such knowledgeable authors, I think that readers will find good advice if there is an area where they need it.

I really doubt there is anything here that can't be found online. Apache's popularity and wide use mean that there is a lot of information out there. The problem is of course that this abundance of information makes it difficult at times to track down what is best or at times what is even accurate. In this book the reader gets the experience and knowledge of two experts in the subject matter, nicely laid out before them. For the person who values quick and accurate information over spending time sifting, this book provides just the time saver that they want.

The index is solid, and the table of contents really breaks things down so finding things is very easy. Like many new O'Reilly titles, this comes with 45 days of access to the book in electronic format through Safari.

You can purchase Apache Cookbook 2nd Edition from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Apache Cookbook 2nd Edition

Comments Filter:
  • My suggestion (Score:3, Interesting)

    by Lord Ender (156273) on Wednesday March 05, 2008 @03:27PM (#22653722) Homepage
    Here's something to cook up: Kill the /cgi-bi/ nonsense already! It was a bad idea from the start. If a file is in my web directory and it has execute permissions, just treat it as a CGI file. Forget that AddHandler business, too. If a file is executable and the directory has +ExecCGI turned on, treat it as CGI already!
    • Re:My suggestion (Score:5, Insightful)

      by synthparadox (770735) on Wednesday March 05, 2008 @03:35PM (#22653842) Homepage
      Thats a good idea but as security features go thats not such a good idea. The point of the cgi-bin directory is to jail the binaries in that folder. That way if by some reason you put up some script that had some security holes and it was used to create a new phishing page or something it would only be able to exist in the cgi-bin directory instead of being hidden somewhere in a mass collection of folders.
      • /cgi-bin/ doesn't jail anything. Please explain how finding a SQL injection in crappybank.com/cgi-bin/index.cgi has any less risk than finding a SQL injection in crappybank.com/index.cgi?

        That's not a jail by any definition.
        • Who said anything about SQL injection? I was talking about files created without your permission. They'd only be runnable in the cgi-bin folder.
          • What does that help? First, an attacker who found a way to control a cgi script would only have permissions of the web server, so he wouldn't be able to WRITE new files anywhere without privilege escalation. If he did have privilege escalation, he could write files anywhere with equal ease.

            Again, where is the security benefit of cgi-bin either way?
    • by an.echte.trilingue (1063180) on Wednesday March 05, 2008 @04:44PM (#22654814) Homepage
      What ever you do, don't file a bug report. I filed one years ago to fix a spelling mistake [wikipedia.org], and its still there.
  • 1 server 1 cup Apache 3 Tbs Linux (note that linux comes in many flavors and chef should select to taste) a dash of GUI selection let server simmer and slowly add Linux to taste dress and add Apache. let bind. extract and add GUI selection. Garnish and serve! Note: Linux can be fatty depending on cut. If desired, user can trim as necessary.
    • by CaptainPatent (1087643) on Wednesday March 05, 2008 @04:12PM (#22654404) Journal
      My apologies for the lack of formatting... above post should have read:

      1 server
      1 cup Apache
      3 Tbs Linux (note that linux comes in many flavors and chef should select to taste)
      a dash of GUI selection

      Let server simmer and slowly add Linux to taste
      Dress and add Apache - let bind.
      Extract and add GUI selection.
      Garnish and serve!

      Note: Linux can be fatty depending on cut. If desired, user can trim as necessary.
    • Re: (Score:2, Funny)

      by Hannes2000 (1113397)

      1 server 1 cup


      You have to be careful these days when posting things involving enumerations of random things and one cup.

      I almost tried to imagine... oh nevermind.
  • Er, sorry, I thought this thread was about something else. [galen-frysinger.com]
  • bleh (Score:1, Informative)

    by ionix5891 (1228718)
    Apache is very slow when it comes to php

    i run several sites and 2 are bigger than slashdot ;)

    and we use lighttpd and nginx with php running as fast-cgi

    the switch literally means we need to rent less servers now! and the sites are alot snappier
    • by Deagol (323173)
      Apache 1.x or 2.x? Seriously, I'd love a link to your benchmark data. Quite the opposite, I manage a very *small* site for a client, and I need to eek out the absolute most from the aging server they rent. I did some half-assed benchmarks between the existing Apache 1.3 install vs whatever the latest lighttpd version in FreeBSD's ports was at the time, and it was a big improvement. However, I then threw on Apache 2.2, and the difference between it and lighttpd were negligible. They require PHP, as well
  • I know this is a bit off-subject, but every time I hear people talk about Apache, I wonder if it's not starting to lose ground. Look at a lot of the new "Web 2.0" sites -- they often run less monolithic servers, which often support FCGI and other features natively. I am talking about nginx [nginx.net], lighthttpd [lighttpd.net] and the like. Will these stay a niche market or is Apache going to feel the competition?
  • ...which for me is one of the trickier bits of Apache, get Rich Bowen's excellent mod_rewrite book [amazon.com]. It's helped me figure out a bunch of complicated stuff and even has a great chapter on when _not_ to use mod_rewrite - e.g., if a RedirectMatch will do the trick, use that instead.
  • Wow ... filler much? How many server admins or developers have been urgently looking for that?
  • I don't know why TFA encouraged users to look at the TOC and didn't link to it [oreilly.com]. (Even Amazon doesn't bother to include it.)

    Looks like most of the sections are obvious to anyone experienced with Apache (as I am, I support it at work). But a few things in there may be worth getting my hands on a copy.

There's a whole WORLD in a mud puddle! -- Doug Clifford

Working...