Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apache Cookbook 2nd Edition

samzenpus posted more than 6 years ago | from the read-all-about-it dept.

Book Reviews 42

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.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.

cancel ×

42 comments

Sorry! There are no comments related to the filter you selected.

Today's Apache is Tomorrow's Sendmail (-1, Flamebait)

krog (25663) | more than 6 years ago | (#22653666)

Discuss.

Re:Today's Apache is Tomorrow's Sendmail (1)

Hatta (162192) | more than 6 years ago | (#22654700)

What's tomorrow's postfix?

Re:Today's Apache is Tomorrow's Sendmail (1)

tcopeland (32225) | more than 6 years ago | (#22654968)

> What's tomorrow's postfix?

Maybe nginx [nginx.net] ? highscalability.com has an article about a popular Rails Facebook app [highscalability.com] that replaced a hardware load balancer with a dedicated nginx box. 10M hits a day, not bad.

Re:Today's Apache is Tomorrow's Sendmail (1)

krog (25663) | more than 6 years ago | (#22655858)

or maybe you could actually learn what 'postfix' is.

to address the GP: it isn't clear (to me, at least) what the successor to Postfix will be. There is no successor thus far which makes Postfix look thoroughly old-fashioned.

Re:Today's Apache is Tomorrow's Sendmail (1)

tcopeland (32225) | more than 6 years ago | (#22656042)

> or maybe you could actually learn what 'postfix' is.

You're right, I misunderstood the post. I thought the question was "what's the successor to Apache that will do for Sendmail what Postfix did - e.g., make it obsolete?"

Re:Today's Apache is Tomorrow's Sendmail (1)

Hatta (162192) | more than 6 years ago | (#22659610)

You understood me correctly. That is indeed what I meant.

Re:Today's Apache is Tomorrow's Sendma- Redundant? (1, Informative)

Culture20 (968837) | more than 6 years ago | (#22655120)

Mods? How can the first post be redundant? Troll maybe, or flamebait, but redundancy requires a similar post first.

Re:Today's Apache is Tomorrow's Sendma- Redundant? (2, Funny)

Victor_0x53h (1164907) | more than 6 years ago | (#22655300)

The moderators are here to arbitrarily wield their power of authority so we fear them!

Re:Today's Apache is Tomorrow's Sendma- Redundant? (1)

moderatorrater (1095745) | more than 6 years ago | (#22655560)

(Score:1, Offtopic)
At least they have a sense of humor...

Re:Today's Apache is Tomorrow's Sendma- Redundant? (1)

billcopc (196330) | more than 6 years ago | (#22658502)

Moderation is Web 1.0. Random is the new postfix!

Re:Today's Apache is Tomorrow's Sendma- Redundant? (1)

owlstead (636356) | more than 6 years ago | (#22663756)

It might be redundant because it states information that is already known to everybody interested in the article. E.g. the Sun looks yellow in the afternoon when discussing sun-spots. Or that Apache may be the next redundant piece of software. Yes, it could be, so what?

In this case it's a clear case of trolling, but hell, as long as they mod it into oblivion, I don't particularly care. In all honestly, I only ever look at +x funny as a special marker. I don't look at -x articles except when meta-moderating, and I don't care if it is +x informative or +x interesting except when moderating myself (other people could care, you never know).

My suggestion (2, Interesting)

Lord Ender (156273) | more than 6 years ago | (#22653722)

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 (4, Insightful)

synthparadox (770735) | more than 6 years ago | (#22653842)

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.

Re:My suggestion (1)

Lord Ender (156273) | more than 6 years ago | (#22655962)

/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.

Re:My suggestion (1)

synthparadox (770735) | more than 6 years ago | (#22656180)

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.

Re:My suggestion (1)

Lord Ender (156273) | more than 6 years ago | (#22657582)

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?

Re:My suggestion (0)

Anonymous Coward | more than 6 years ago | (#22653890)

Come on.. are you serious? I have worked in University sites where hundreds of user home folders were mapped into out web space. Do you trust every single person to do the right thing, and make sure only those files meant to be executables have the correct permissions? Let alone allow Joe Sixpack to install CGI scripts that access databases.. they'd have to really know what they're doing to avoid SQL injection.

Apache has fine grained control over what users may and may not be able to do.. and thats just fine.

Slightly off topic: am I the only one who remembers the old days well enough to know why the configuration is still an interesting mix of XML style and simple "Attribute: value" :-) ? Hint.. Ari.. Rob..

Re:My suggestion (1)

Lord Ender (156273) | more than 6 years ago | (#22657628)

A uni shouldn't let the kids have +ExecCGI at all on a shared system. You will absolutely get hacked if you do that, no matter what your directory structure is.

Re:My suggestion (3, Funny)

an.echte.trilingue (1063180) | more than 6 years ago | (#22654814)

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.

Glad to see the review (-1, Offtopic)

sconeu (64226) | more than 6 years ago | (#22653748)

I picked this book up as a door prize at SCALE [socallinuxexpo.com] a couple of weeks ago, and haven't had a chance to read it yet.

O'reilly is garbage (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#22653830)

O'reilly is garbage

Re:O'reilly is garbage (0)

Anonymous Coward | more than 6 years ago | (#22654020)

Oh shit! A single anonymous comment stating that O'Reilly is garbage. I had better burn all my O'Reilly books.

PROTIP: you should stick to the "For Dummies" line of books.

What about mod_perl (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#22654040)

When is mod_perl going to be ported to Apache 2?

Re:What about mod_perl (1)

simcop2387 (703011) | more than 6 years ago | (#22654212)

umm at least 2 years ago?
http://perl.apache.org/download/index.html

Hmm. Apache cookbook. (-1)

Anonymous Coward | more than 6 years ago | (#22654054)

How, white man. Buy my Apache cookbook. Good recipe for maize.

frist p5ot (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22654288)

Apache cookbook summary of summary: (1)

CaptainPatent (1087643) | more than 6 years ago | (#22654292)

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:Apache cookbook summary of summary: (4, Funny)

CaptainPatent (1087643) | more than 6 years ago | (#22654404)

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:Apache cookbook summary of summary: (0)

Anonymous Coward | more than 6 years ago | (#22656528)

But what of the garnish, for surely that could make or break the meal

A moldy old sprig of php, or some nice crunchy python?

Re:Apache cookbook summary of summary: (2, Funny)

Hannes2000 (1113397) | more than 6 years ago | (#22655186)

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.

What's cooking? oh wait (1)

Jabbrwokk (1015725) | more than 6 years ago | (#22654514)

Er, sorry, I thought this thread was about something else. [galen-frysinger.com]

bleh (2, Informative)

ionix5891 (1228718) | more than 6 years ago | (#22654556)

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

Re:bleh (1)

Deagol (323173) | more than 6 years ago | (#22656218)

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'm admittedly not well versed in current web server benchmarking methodology, so I could have been way off the mark in my tests. I've read a few case studies online about what you propose, and more than a few seem to think Apache 2.2 stacks up pretty well against lighttpd.

I'm in no way biased for or against the "older" popular servers out there. I prefer postfix to sendmail, though I still prefer BIND to the light-weight alternatives. Apache's complexity sometimes bugs me, so I'm always open for the option of ditching it.

Disappointed... (0)

Anonymous Coward | more than 6 years ago | (#22654640)

I was really looking forward to reading about native American cooking.

Re:Disappointed... (1)

stoolpigeon (454276) | more than 6 years ago | (#22654924)

here you go [amazon.com]

Alternative web servers? (1)

twistah (194990) | more than 6 years ago | (#22654978)

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?

Re:Alternative web servers? (0)

Anonymous Coward | more than 6 years ago | (#22655346)

less monolithic servers, which often support FCGI and other features natively

What?

If all you need is mod_rewrite help... (1)

tcopeland (32225) | more than 6 years ago | (#22655084)

...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.

Install Issue (0)

Anonymous Coward | more than 6 years ago | (#22655350)

So I am trying to write a python script to install apache on windows. It works, except document root doesn't get set correctly.

Here is the command I am using(I shortened the install file name if you are wondering):

apache_2.2.4-win32.msi /quiet /norestart installdir="C:\Program files\SomeApp\Apache\" SERVERROOT="C:\Program files\SomeApp\Apache\" ALLUSERS=1 SERVERNAME=10.1.5.1:80 SERVERPORT=80 apachehtdocsdir="C:\Program Files\SomeApp\Web\" DOCUMNETROOT="C:\Program Files\SomeApp\Web\" DIRECTORY="C:\Program Files\SomeApp\Web\" LISTEN=80"

ANy ideas whats wrong? Anyone know what args to send to set Document Root to C:\Program Files\SomeApp\Web?? Everything works except this setting.

Thanks!

Re:Install Issue (0)

Anonymous Coward | more than 6 years ago | (#22658318)

I couldn't resist ...

> DOCUMNETROOT="C:\Program Files\SomeApp\Web\"

s/MNET/MENT/

a chapter on directory listings? (1)

nuzak (959558) | more than 6 years ago | (#22655848)

Wow ... filler much? How many server admins or developers have been urgently looking for that?

Table of contents (1)

Micah (278) | more than 6 years ago | (#22660080)

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.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>