Tag Archives: httpd

Features, not lies

A colleague is attending the nginx conference in Austin this week, and shared with me several anecdotes in which a speaker preached misinformation – or if I want to be generous, grievously outdated information – about Apache httpd, to support the notion that nginx is better.

This led to the following:

 

Each time I have encountered nginx people at conferences, and attended their talks, they have compared nginx to grossly misconfigured, 10 year old installations of Apache httpd 2.2 to support their claim that nginx is leaner, faster, and easier to administer.

Here’s the thing. nginx is a solid project. I have zero beef with the software itself. I have used it myself, when the need arose. What I object to is the habit of the fans of nginx to lie (or exaggerate, or just spout uninformed opinions) to make themselves look better. If you must compare, compare our latest to your latest, and have experts correctly configure each. That way, each will show where it shines, and where it doesn’t.

It is possible to configure ANY software badly. This is why it’s almost always a bad idea for an expert on SoftwareA, who knows little or nothing about SoftwareB, to compare them head to head – they’ll invariably be comparing a well-configured A to a less than optimally configured B. And in the case of nginx vs Apache httpd, these guys almost always use 2.2 or 1.3 as an example of … well, all of the things that 2.4 fixed. 5 years ago.

Any intro to marketing class will tell you that you need to talk about your own strengths more than you talk about the other guy’s weaknesses. This is a message that nginx and presidential candidates seem to have missed. And, in the case of software, it’s even more important, because whereas Donald Trump will always be a monster, every time you point out a legitimate shortcoming in Apache httpd, we fix it.

Convert an Apache httpd password file to dbm

If you have a textfile password file, and you want to convert it to a dbm database for use with mod_authn_dbm, this can be done as follows:

htdbm -cbp passwords.dbm bogus bogus
awk ‘BEGIN { FS=”:” }; {system (“htdbm -bp passwords.dbm ” $1 ” ”  $2)}’ passwords
htdbm -x bogus

This assumes that the file `passwords` is your existing password file, and that you wish to create a dbm database `passwords.dbm`

The -b flag says that the passwords will be provided on the command line. The -p flag says not to encrypt the password – because it’s already encrypted.

This feature used to be available in the `dbmmanage` utility, as an `import` argument, but that utility is no longer included in the httpd packages for the Fedora/CentOS and Debian/Ubuntu Linux distro families, so we have to make do with htdbm.

I’m stashing this here for posterity, since I just spent a half hour getting the awk syntax right.

The first line creates a starter dbm with a single bogus entry, and the third line cleans up that bogus entry.

Festina Lente

5 Comments

FestinaLenteCorrect

On Wednesday morning I learned that my long-time friend Nóirín Plunkett has just suddenly passed away.

Update: It’s been mentioned that Nóirín stated, on their Twitter profile, a preference for the personal pronouns they/their. It’s been mentioned that I should update the below post to reflect that preference. Grief is a weird thing. We remember people as we remember them, not as other people want us to remember them. I knew Nóirín in an earlier chapter of their life, and I don’t intend any disrespect by how I recount those memories. Nóirín influenced different people in different ways. To me, Nóirín was a grammar geek, a friend, an unstoppable force, and a deep enigma. I miss the Nóirín that I knew, and I’m aware that Nóirín grew into a different person in their later years. Grief is both a very public thing and a very personal thing. I mean no disrespect of either Nóirín nor of their other friends and family. I just remember Nóirín differently than you do, and that’s probably ok.

I first “met” Nóirín on the Apache httpd documentation list, where they helped in the process of making the documentation into a literate manual, with consistent grammar, reasonable organization, and a more professional face. I then met them, in person, for the first time, at the ApacheCon planning meetings in Dublin, where they arrived with Colm and whipped things into order, imposing a great deal of organization on what had been a pretty chaotic process in previous years. I also had the great privilege of spending time in their home with her family while we were there, and these are some of the happiest memories I have of our friendship.

Nóirín contributed a great deal to the Apache Software Foundation over the years in a number of places. They continued her work on the httpd docs for a while, but began to move into community-facing things, such as ApacheCon, where they served as Conference Committee chair for a few years. They were  instrumental in making the ASF more clueful about diversity issues. They also served a year on the board of directors.

In recent years, Nóirín has been more involved with the larger effort to improve the plight of women in technology, and their direct involvement in Apache has faded, and we’ve missed them. We will now miss them even more.

Nóirín’s motto was Festina Lente – Hasten Slowly, and this embodies their approach to life. They considered things carefully, and rushed to get things done, because life is too short to get everything accomplished that we put our minds to. In the end, theirs was far, far too short.

It’s also a jarring reminder that you may never have another chance to resolve that disagreement, so you’d better do it now, before it’s too late.

Goodbye, friend.

noirin_small

If you knew Nóirín, or benefited from her work, please consider donating to St John Abulance in their name.

Blocking comment spam with mod_security

I’ve mentioned before that I use mod_security to (partially) prevent comment spam on this site. The trouble with spam is that it evolves, so it’s a constant arms race.

I’ve noticed in the last few months that the spam on this site typically has a URL as the comment name. There’s also a URL field in the comment form, with a note on it that you shouldn’t fill it out. Then, in httpd.conf, I have the following.

SecDataDir /tmp
SecTmpDir /tmp
SecRequestBodyAccess On
SecDefaultAction log,deny,status:406,capture,phase:2,t:lowercase

# Reject comments where the name contains a URL
SecRule ARGS:comment_name “https?://”

# Also, reject comments where the url field contains a URL
SecRule ARGS:comment_url “https?://”

Note that that config is specific to the Habari blogging platform. You’d need to tweak the names of the fields (comment_name and comment_url) for whatever blogging platform you’re using.

I haven’t had any spam since putting this in place, but I’ve had several legitimate comments that, ordinarily, would probably have gotten lost in the noise of moderating hundreds of spam messages.

I don’t believe for a moment that this is a permanent solution, but it at least stems the flood for a moment so I can catch my breath.

I also have a bunch of legacy rules, like:

SecRule ARGS “(zoloft|acyclovir|zithromax)” “msg:’Pharm spam'”

(which, ironically, prevented me publishing this article until I disabled it!) but those require constant maintenance as the spam trends shift from week to week.

Come see me at ApacheCon NA 2014

In April I will be speaking at ApacheCon North America in Denver, Colorado. I’ve had two talks accepted:

Configurable Configuration is a talk about some of the new shiny configuration syntax available in Apache httpd 2.4 – stuff like the If/ElseIf/Else syntax in configuration files, the new expression evaluation engine, and mod_macro for scriptable configuration blocks, for starters.

Demystifying mod_rewrite will drag you kicking and screaming from being a mod_rewrite newbie to being a mod_rewrite expert. You don’t dare miss it.

We’re also presenting two whole days of Apache http server content – code-named “httpd.conf” – get it?

And there’s ten tracks of amazing content across more than 70 projects from the Apache Software Foundation.

Register at na.apachecon.com by March 14 to get the early rate.

Be careful what you start

I’ve committed a few patches over the last few weeks from a possible new contributor to the Apache HTTP Server documentation effort. Today I warned him that if he keeps it up, there’s a chance that someone will propose that he be given commit access, and you never know where that can lead.

It reminded me of a day just a short time ago (ok, 12 years … ) when someone committed a few initial patches from me. And look where it took me.

“It’s a dangerous business, Frodo, going out your door. You step onto the road, and if you don’t keep your feet, there’s no knowing where you might be swept off to.”

Joshua Slive

In September of 2000, I made my first commit to the Apache HTTP Server documentation. To be exact, it was on September 12th.

On September 8th, four days earlier, Joshua Slive made his first commit, and from that point went on to completely change the way that we did documentation. We had been editing HTML files. He converted everything to XML, and built a transformation process to convert them to XHTML, as well as a variety of other formats. This made the documentation more useful, but also much easier to write. And it made the translation process much easier. (No, it certainly wasn’t only Joshua that did this, but he took the helm at this time and made it happen, with the help of many others.)

Then, when he went to grad school, Joshua stopped being quite so active. His last commit was on March 12, 2008, nearly four years ago.

I mention all of this today because last night, according to Ohloh, four years to the week after Joshua stopped committing, I *finally* passed him, in total commits.

ohloh

Joshua, thanks for the work that you did. Any time you want to come back and pick up where you left off, we’d be delighted to have you.

Apache HTTP Server PDF documentation

Although I’ve known for a while that it was possible to build the HTTP Server docs as PDF, I never really bothered to find out how. Finally this afternoon I was poking around and figured out how. The latest docs are available in PDF format here, and I’ll try to keep them somewhat fresh, if you want to bookmark that.

Apache HTTPd 2.0 docs (pdf – 3Mb)
Apache HTTPd 2.2 docs (pdf – 4Mb)
Apache HTTPd 2.3 (trunk) docs (pdf – 4Mb)

[DPI]

The Apache Web Server version 2.2.12 released today, including the following nugget of joy:

‘discardpathinfo|DPI’ (discard PATH_INFO)

In per-directory context, the URI each RewriteRule compares against is the concatenation of the current values of the URI and PATH_INFO.

The current URI can be the initial URI as requested by the client, the result of a previous round of mod_rewrite processing, or the result of a prior rule in the current round of mod_rewrite processing.

In contrast, the PATH_INFO that is appended to the URI before each rule reflects only the value of PATH_INFO before this round of mod_rewrite processing. As a consequence, if large portions of the URI are matched and copied into a substitution in multiple RewriteRule directives, without regard for which parts of the URI came from the current PATH_INFO, the final URI may have multiple copies of PATH_INFO appended to it.

Use this flag on any substitution where the PATH_INFO that resulted from the previous mapping of this request to the filesystem is not of interest. This flag permanently forgets the PATH_INFO established before this round of mod_rewrite processing began. PATH_INFO will not be recalculated until the current round of mod_rewrite processing completes. Subsequent rules during this round of processing will see only the direct result of substitutions, without any PATH_INFO appended.

It might also be handy, some day, to have a [DQS] flag that discards the query string explicitly, rather than having to do silly tricks to make it disappear.