Slashdot Mirror
Apache Cookbook
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.
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!
Amazon Link
Froogle Link
Why is the 1.3 still so popular? Is the version 2 still unstable or something?
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.
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.
Prescriptive grammar:linguistics
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, later switched to Mathopd, but I consider THTTPD 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.)
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
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
Servlets/JSP are handled by Jakarta/Tomcat, webservices are handled by Axis both are Apache projects
Sehr geehrter Toilettenbenutzer!
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"
Thought I was going to get some good Native American cooking recipes.
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 from Amazon. Note that the first review matches the above review.
Exhibit B: The first plagiarization post in this thread. Note how it is eerily similar to the second customer review in the Amazon page.
Exhibit C: relrelrel's comment (as an Anonymous Coward) complaining about the first time I pointed out his plagiarization. But if it truly was your own comment (which is possible, I concede), how is it possible that you actually wrote both Amazon customer reviews??
I rest my case, your honor.
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.
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.
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.
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 may cause security holes.
Dw.
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.
What do you call it when someone is intentionally putting loud, obnoxious statements into circulation, but they aren't exactly trolling? Or is that trolling, too? I don't know--listen to this guy:
"Yes, that's hard but you must admit that I have a point."
Everything about this is calculated to piss off the Slashdot reader--the overt arrogance (Mensa membership!?? Are you kidding!??), the attempt to seem like an authority on the subject by making overly specific assertions, even down to the bad punctuation! On top of that, he starts throwing down about PHP and Perl--yeah, when I want to make a well-reasoned argument, the first thing I do is start flaming a religious OSS obsession. Good strategy.
Now, I don't want to be too judgemental, because I can get pretty snippy myself (it's good to blow off steam by smacking someone around), but I think this goes further--it's a calculated attempt to piss people off for the purpose of pissing people off.
His argument doesn't even make any sense--the *right* tools for a job, ANY job, are the tools that fit that particular job. For small, non-scaling apps that need quick and easy-to-maintain/modify structures, PHP/Perl and Apache work wonderfully. Why the fuck should anyone start fucking around with Corba for building a web forum? Especially when the skills to work in PHP are much more common, and therefore cheaper?
I'm not trying to point out that he's wrong--I'm just trying to show how totally ungrounded the post is.
I've seen this account do this before--not always, so maybe it's not a straight-up troll account--but he IS just being an asshole.
You should be running your server through the ringer 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.
You must not do much with sendmail....
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
Maybe the part that runs ASP/ASP.NET code? Out of the box, with no additional software to install. I dunno... Who's deluded?