Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Software Book Reviews Apache IT Technology

Apache Cookbook 172

Posted by timothy from the add-measure-stir dept.
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.
This discussion has been archived. No new comments can be posted.

Apache Cookbook More

Apache Cookbook

Comments Filter:

  • Cookbook format... (Score:5, Interesting)

    by neiffer ( 698776 ) * on Thursday January 15, 2004 @01:03PM (#7987687) Homepage
    I really like the cookbook format as it allows me to see solutions in application. I have often found solutions to different (but related problems) by using the skill set. I'd love to pick this up!

  • As always.... (Score:2, Informative)

    by herrvinny ( 698679 )
    Amazon Link [amazon.com]

    Froogle Link [google.com]

  • Why (Score:5, Interesting)

    by eille-la ( 600064 ) on Thursday January 15, 2004 @01:05PM (#7987712)
    Why is the 1.3 still so popular? Is the version 2 still unstable or something?

    • Re:Why (Score:5, Informative)

      by Erratio ( 570164 ) on Thursday January 15, 2004 @01:07PM (#7987755)
      Version 2 is a vastly different program. The framework is different and the modules are different. If people don't need any of the features from 2 and 1.3 continues to be stable and secure, then it wouldn't make sense for most people to upgrade, or for some people to take the time at the moment to familiarize themselves with the new methods of doing things.

    • Re:Why (Score:4, Interesting)

      by elviscious ( 681985 ) on Thursday January 15, 2004 @01:09PM (#7987770)
      PHP is one reason. Supposedly very unstable on 2.0

      • True That! (Score:1, Informative)

        by Anonymous Coward
        I mean when php breaks under 2.0 you do not know if it was php or apache that broke. Under 1.3 you can be pretty damn sure that it was php that broke due to one of their "keep the language functions changing randomly for no reason so as to break apps" approach to keeping php going.

        • I call FUD.

          One of the primary concerns of PHP upgrades over the past couple years has been backwards compatibility.

          As a result, we're stuck with with some nasties (bad decisions early in the life of the PHP function library) like : x(needle, haystack) vs y(haystack, needle).

          Those suck, yes, but at least your apps don't break.

          S
          • Its not FUD and the apps can break. Off the top of my head I can remember these things breaking:

            Various issues with session variables being registered globally.
            Register globals.
            Safe Mode (oh, you wanted to create directories? hope you have the same gid as the webserver and write access to php.ini).
            Pass by Reference.
            Running MySQL queries inside fetch_array loops.
            One version suddenly wouldn't allow $array['key'], had to be $array["key"], this got fixed shortly after release.

            The 2 latter didn't have config o
      • Does anyone have any decent references to the claimed problems with PHP and Apache2?

        I googled on "php apache2 (bug|problem|issue|sucks)" and only got 34,500 hits so it can't suck that bad.

        That being said, I have been using PHP4/apache2 exclusively for at least 18 months and I haven't had any problems.

        • Re:Why (Score:3, Funny)

          by beebware ( 149208 )
          I googled on "php apache2 (bug|problem|issue|sucks)" and only got 34,500 hits so it can't suck that bad.
          True, until you do a search for "php apache2 (works|working|good)" and only get 17,500 results....

          • Re:Why (Score:2, Informative)

            by lisany ( 700361 )

            People rarely speak up when things work. Good thing, too. Who wants to have their search results cluttered with "I just installed Apache and it works!" pages?

          • If you use 4 possibilities for the bad, use 4 for the good. php apache2 (works|working|good|success) gives 26,200 results. Not really that bad when you consider that people are more likely to complain than praise in newsgroups.

      • Re:Why (Score:2, Informative)

        by Anonymous Coward
        That's right. Supposedly, it's very unstable. Or, if you want to take the opinion of somebody with actual experience in running PHP (4.3.x) with Apache (2.0.4x), it's just as stable as running Apache 1.3 with PHP, as long as you stick to the prefork MPM (the compiled-in default).

    • Re:Why (Score:5, Interesting)

      by markjl ( 151828 ) on Thursday January 15, 2004 @01:22PM (#7987961)

      Short answer: Because of it's legacy and partially because 2.x isn't a revolutionary step forward and it took a while for 2.x to get out of beta. Also, 2.x probably benefitted the Windows platform and new module writers moreso than anyone else, IMHO.

      1.3x is what most people know, what most Apache modules are written for, and what most of the articles and tutorials on the web describe.

      Another example: Apache Toolbox [apachetoolbox.com] still only compiles 1.3x and associated modules for you. (BTW: this is a great resource for trying new modules out when you can't find an RPM with what you need.)

      It's only now that I'm migrating production from 1.3x to 2.x, because I had seen that people had headaches getting PHP working (but no longer) and I waited for stable ports of some modules that I used in 1.3x.

      I do consider 2.048 to be worthy now, lots of RPMs and modules written for it.


      --Mark
      [ My opinions are my own, but you may share them! ]

  • Apache is damned good. (Score:3, Insightful)

    by chadw17 ( 308037 ) on Thursday January 15, 2004 @01:05PM (#7987724)
    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.
    • I think part of it is because there are so many good hacks for 1.3 that don't necessarily work in 2, so migration is slow...

    • Re:Apache is damned good. (Score:5, Informative)

      by pclinger ( 114364 ) on Thursday January 15, 2004 @01:09PM (#7987771) Homepage Journal
      You may want to check out webmin [webmin.com], it has a useful GUI interface for Apache and everything else on your system.
    • Webmin works pretty well for a GUI Apache config editor, although I have to confess that I will often end up going back to editing httpd.conf by hand; if you know what you're doing it is usually a lot faster. Not that I always know what I'm doing!
    • Unless I'm missing something, doing what you're talking about shouldn't take more than a couple lines to set-up and a couple lines per domain.
      • Probably true, I was attempting to do this for the first time, and also route them via different ports as well. 80 VS 8080 and such. It was an attempt to make it invisible to the user what was being done behind the scenes. Pretty easy stuff in retrospect.

        The way it was done was pretty much just a couple of lines, which had to be perfectly set up. The largest error, definitely a user error on my part was attempting to modify too much of the httpd.conf before I really realized what I was doing. Googling
        • If you're taking that approach, you can set up a directory to hold all the virtual host configurations and just put a line in the main httpd.conf file to include all the files from that directory. That way when you add a new virtual host you can just copy one of the existing ones and modify the new file. Give 'em names that match their domains and it's easy to go back and make changes to a virtual host's configuration as necessary.

          That approach makes it easy to script adding new domains. You can then go

    • Re:Apache is damned good. (Score:4, Informative)

      by llamalicious ( 448215 ) on Thursday January 15, 2004 @01:31PM (#7988068) Journal
      If you're talking about virtual hosting, and you're setting up many many hosts with separate VirtualHost directives, it may be time to look at mod_rewrite ... and the documentation on it at httpd.apache.org. There's a section about using mod_rewrite for mass virtual hosting, which, depending on your situation, might be useful.

  • Only if you want (Score:4, Interesting)

    by leoboiko ( 462141 ) <leoboiko@NOSpaM.gmail.com> on Thursday January 15, 2004 @01:06PM (#7987728) Homepage
    The 'httpd.conf' file is a long and critical one.


    But if you want you can use a more modular approach instead of keeping everything in one single file. Debian sid is currently experimenting with this in interesting ways in the apache2 packages.
    • My favourite is simply

      # Suck in configs for the various sites...
      #
      include /usr/local/etc/www-sites

      And simply fill that directory with small little config files, one per site or logical function. Or often, symbolic links to the actual files in their project directory which are under cvs control. (Use something like .../*.conf to limit where needed).

      Some care is needed with perms; apache will quite happily such in what is there; and careless use of symlink or allowing the creation of such

  • Yes, it's difficult. (Score:5, Informative)

    by SharpFang ( 651121 ) on Thursday January 15, 2004 @01:08PM (#7987757) Homepage Journal
    The 'httpd.conf' file is a long and critical one.

    For this reason, and for several more, whenever I don't need any of the multitude of Apache features, I install one of "mini servers" - for quite a while I was going on Boa [boa.org], later switched to Mathopd [mathopd.org], but I consider THTTPD [acme.com] or any of several other "tiny" webservers. Small, smart, fast and easy to configure. WAY easier than Apache.
    (yeah, you may think you configured Apache right because it works... but what if you just opened several security holes you didn't understand? It's much better to have a tiny config file you can use for 8 things out of which you need 6, and understand all thoroughly, than one with 400 things out of which you need 12 and understand thoroughly less than 50.)

    • Sure but... (Score:3, Funny)

      by telbij ( 465356 )
      What if you need 20 out of 400 and understand 100? Or understand 18 needing 15 of 32, or even worse, need 12 out of 11 with understanding of 2. Or 13, 18, 4597, 129, 97...

      Obviously picking the right web server can be a tough proposition.
    • Here's another idea: a config file in which you enable six things out of those 400, and leave the rest turned off.

      Shockingly, it's pretty easy to do that in Apache. Anything that doesn't look immediately neccessary in a LoadModule command gets commented out.

      On one of my servers, the httpd.conf file is 277 lines long, a fairly daunting number. If you grep for lines starting with an alphanumeric character (which lets out comments and whitespace), you're down to 48 lines, hardly a scary number at all.

    • Test after every config/code change (Score:4, Informative)

      by justMichael ( 606509 ) on Thursday January 15, 2004 @02:15PM (#7988699) Homepage
      You should be running your server through the ringer [nessus.org] every time you change something or new holes are found, every 2 weeks is a decent number.

      This is just one of many steps to consider ;-)

      It's a good idea to have a box local that is configured exactly like your live one for this, the tests can eat a lot of bandwidth and make a mess out of your logs. Of course if you are testing the box as a whole there is no substitute for testing the live box.

  • Sounds great. (Score:5, Insightful)

    by ActionPlant ( 721843 ) on Thursday January 15, 2004 @01:09PM (#7987779) Homepage
    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,
    • Why can't you run a browser while you configure the server?
      • Because the server I was installing was on a linux box, and I was learning the whole thing from scratch. I hadn't connected yet because I was replacing an existing server by myself and didn't want to do it live.

        It's a long, unnecessary way around, I've since learned. The book would still have been helpful though, and I still plan to get it.

        Damon,

  • Use Apache! (Score:1, Interesting)

    by relrelrel ( 737051 )
    Has there ever been an open source program as successful as the Apache web server? If we leave aside the various p2p freeware for music sharing, then perhaps none. Certainly, if we restrict our survey to web servers, Apache is head and shoulders above its peers. It is currently in its second major revision, 2.0, and is very stable and mature.

    This book gives you a good grounding in both installing and running it, even if you have never run a website before. Those of you who used earlier versions may recall
    • The IBM J2EE web server is a rebadged version of Apache if I remember correctly.
    • Jakarta Tomcat [apache.org], part of the Apache project, has no problem working with Apache. There is an Apache plugin available.

    • Re:Use Apache! (Score:1, Informative)

      by Saganaga ( 167162 )
      Is it that hard to write your own comment, instead of plagiarizing someone else's [amazon.com]?

    • Re:Use Apache! (Score:4, Informative)

      by curtisk ( 191737 ) on Thursday January 15, 2004 @01:18PM (#7987902) Homepage Journal
      Servlets/JSP are handled by Jakarta/Tomcat [apache.org], webservices are handled by Axis [apache.org] both are Apache projects
    • Various P2P software? What about all the other daemons? Sendmail, BIND, OpenSSH (and of course Linux and the base GNU stuff though that's a little unfair). There are a lot other probably often overlooked types of programs too, but no less important. Apache is probably one of the most successful, but I don't think it's primary competition comes from P2P software.
    • Umm...I know for a fact that Oracle uses Apache 1.3x for their java app server. I believe IBM does as well. I don't know of any Java servlet container that doent include an apache plugin. What was your point about Apache and Java again?
    • mod_mono [apacheworld.org] is an apache (1.3, 2) module that lets you run asp.net applications (aspx pages, http modules, web services, etc.) using mono.

    • Re:Use Apache! (Score:4, Insightful)

      by KlomDark ( 6370 ) on Thursday January 15, 2004 @02:06PM (#7988561) Homepage Journal
      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.
      • You're buying into the Microsoft delusion that the web server itself should support application level functionality

        So which part of IIS is an application server pray tell? I think you're at the deluded end of the stick my friend.

        • Re:Use Apache! (Score:3, Informative)

          by KlomDark ( 6370 )
          Maybe the part that runs ASP/ASP.NET code? Out of the box, with no additional software to install. I dunno... Who's deluded?
          • I think you'll find that ASP.NET runs out of process from IIS. And you can configure IIS to run classic ASP inproc or out of process.

            IIS isn't an app server and never was intended to be. Depending on the mapping of an extension it hands off to the relevant ISAPI extension.

            MTS/COM+ Services is where the app server is at.

            And so what if it runs out of the box...?

            • I'm not talking out of process, give me more credit than that. You could do that with oldschool ASP. (Non-.NET ASP) I'm talking multi-server.

              Here's what I want to know: How can one set up an architecture with two servers where Server One runs ONLY IIS and handles all the web traffic, and passes all its ASP.NET processing off to Server Two, which only does ASP.NET processing?

              After that, assuming you can do that, then how do you go about scaling that with Windows? Where you have multiple IIS boxes passing t
              • Darnit, the sentence "There's a big difference between splitting functionality up between two (or more) servers, and actually building a serious, redundant, scalable nTier architecture." should have read:

                There's a big difference between splitting functionality up between two (or more) servers, actually building a serious, redundant, scalable nTier architecture, and simply running the ASP.NET stuff in an out-of-process mode.

                Actually, I don't need to know how to run IIS itself in a redundant mode, WLBS or a
                • A serious, redundant, scalable n-Tier architected solution can be built using the .NET Framework.

                  People forget or don't get that ASP.NET is a presentation tier technology (like JSP or PHP) and is just a part of the framework - so therefore why wouldn't I want my presentation tier technologies as near to the user i.e. the web server in the first instance?

                  Communication and hand off to the mid tier (built using .NET) is achievable via remoting, web services, MSMQ or using enterprise services (COM+ app proxi
                  • You've got a distorted concept of what should be on the front tier. I guess what you're saying is that what I asked about cannot be done. Even with JSPs, the code is executed on a middleware server everywhere I've worked.
    • Has there ever been an open source program as successful as the Apache web server?
      I think a case can be made that Bind is the most successful and widely used free open source program ever. And Sendmail certainly has proved remarkably successful. And all this free open source software would not be possible without the Gnu Compiler Collection (AKA GCC). However, Apache is clearly special, and the Apache Group in particular is an awesome collection of talented folks.

  • great book (Score:1, Redundant)

    by relrelrel ( 737051 )
    The collaboration of Apache software experts Ken Coar and Rich Bowen, Covering Apache 2.0 & 1.3, Apache Cookbook is a "user friendly" guide and comprehensive reference to the most widely used web server in the world. Offering common problems and solutions; step-by-step walk-throughs; discussion problems; sample codes; worked-out solutions; instructions for tasks such as installing the server or managing a proxy server, and so much more, Apache Cookbook is a "must-have" instructional reference for anyone

    • Re:great book (Score:3, Informative)

      by Saganaga ( 167162 )
      This is the second time in the same thread that you have posted a plagiarized review. What gives? How stupid are you, anyway?

      Exhibit A: The customer review section [amazon.com] from Amazon. Note that the first review matches the above review.

      Exhibit B: The first plagiarization post [slashdot.org] in this thread. Note how it is eerily similar to the second customer review in the Amazon page.

      Exhibit C: relrelrel's comment [slashdot.org] (as an Anonymous Coward) complaining about the first time I pointed out his plagiarization. But if it truly
  • How do I get a virtual host to automatically redirect to a different virtual host and path? I want 'http://mail.foo.bar' to redirect to 'http://www.foo.bar/horde/imp/login.php'. I couldn't figure out how to do this...

  • Crap (Score:4, Funny)

    by Orion442 ( 739483 ) on Thursday January 15, 2004 @01:24PM (#7988001)
    Thought I was going to get some good Native American cooking recipes.
    • "To Serve Man" is a cookbook.
    • I must ask: cooking by Native Americans, or cooking of Native Americans?

      There's a difference, you know.
      • Do you think Mexican food contains people?
        • Oh come on. It was supposed to be a joke. You know, those things that people sometimes laugh at?

          I was merely commenting on the ambiguity of the phrase "Apache Cookbook". Because, you see, you can have a "Mexican Cookbook". But you can also have a "Dessert Cookbook". Get it?? Is it funny now that I explained it? Wheeeeeeee, everybody laugh now!!
        • I know soylent green is made of people.

          (yes, I know it really isn't if you read the book rather than just watch the movie)
    • I actually looked for recipies for Apache cooking, and was not able to find anything. From what I gathered from various cooking and food mailing lists, much of what was eaten by the Apache people prior to the influx of Europeans changed a great deal after the introduction of European foods.

      Anyways (yes, I know you were joking) I'm currently reading "Chasing Shadows", which is about the Apache people during the late 1800s and early 1900s, and I *highly* recommend it as a way to learn about the Apache people
      • I love southwest cooking, most of the NA cooking habits of that region were absorbed into it. Did you read any about how the richness of European food led to diabetes for many people of Native American descent anywhere?
        typing on crack cuz I'm at work
      • Well try Google....I found this book: http://www.cniethammer.com/work4.htm that contains some :)
    • Highly overrated. You can season them however you like, they still taste like chicken.

  • Good thing with apache (Score:3, Insightful)

    by arvindn ( 542080 ) on Thursday January 15, 2004 @01:56PM (#7988441) Homepage Journal
    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.

  • mod_rewrite (Score:3, Funny)

    by elmegil ( 12001 ) on Thursday January 15, 2004 @02:51PM (#7989219) Homepage Journal
    One module alone, mod_rewrite, causes me almost more problems and regex wrestling matches than all other products combined.

    You must not do much with sendmail....

  • the review didn't mention it afaics, and neither does o'reilly, but we have a companion site for this book: Apache-Cookbook.Com [apache-cookbook.com]. that's where we keep the up-to-date errata, the table of contents, and a random recipe-of-the-day. (and soon reviews and review pointers.)

    just fwiw.

Slashdot Top Deals

Over the shoulder supervision is more a need of the manager than the programming task.

Close