Tag Archives: apache

Migrating to 2.0, part two

I got done migrating to Apache 2.0 on Eris. I’m actually still running two daemons. I’m running Dav in its own process, on an alternate port. I built a very stripped-down Apache, taking out all the modules that I did not think I would need. I’ll bet I could make it even more stripped down, but it seems to be pretty good. I’m running it with Worker, and just a few threads.

The other process is bigger – ie more modules – and running SSL as well. I’m running worker on that also, and it really seems to be running faster. I suppose I could be imagining this, but it feels snappier. This could also be because I’m running mod_deflate. I was using mod_gzip before, but this cause some problems, as mentioned in an earlier note.

My other main server is still running 1.3, because I feel better with 1.3 and mod_perl. Hopefully, I can move that to 2.0 real soon now also.

Migrating to Apache 2.0

Now that I have given a “Migrating to Apache 2.0” talk a few times, I
thought it might be a good time to try it myself. Actually, my last PHP
web site went away, and I’m not using mod_perl on the server in
question, so it seemed like a reasonable thing to try. Also, after my
latest frustrations with mod_gzip, a move to mod_deflate seemed like a
good idea as well.

So, I’m moving one of my two main servers to Apache 2.0.

The hardest part of the entire process really seems to be the swap
itself, because there are so many hard-coded path-names laying around
pointing to /usr/local/apache. So I’m building Apache2 in
/usr/local/apache2, I’ll do some symlinking for a bit while I rebuild it
in /usr/local/apache, and then … well, it should just work. I think.

mod_gzip

It appears that mod_gzip keeps work files FOREVER. Don’t say that you want to keep work files, because it will. I appear to have GIGABYTES of mod_gzip work files. And I’ve been backing them up. For months. This is an enormous pain.

Third time’s the charm

DrBacchus’ Journal: Surreal tech support situation

Third time’s the charm. The first two people that I spoke to were not able to help me, and it was not even clear that they understood the problem. This time, I spoke with Tim, who clearly knew what I was talking about. This made the whole conversation much more pleasant.

While he agreed with me as to the problem and the likely solution, it was not quite that simple, since they are, of course, using some mass vhosting module. He was not able to tell me what module, exactly, they were using. Not that it matters – I was just curious. But apparently the account name makes the hostname different from what we are using, and this goes into the mass-vhosting algorithm. He agreed to change the name on the account, which should resolve the problem, but could take several hours to actually happen.

So, we seem to have a happy conclusion to this all. And the next time you call Earthlink support, ask for Tim.

Foiling Nimda

Nimda and Code Red are IIS worms. As an Apache server administrator, you are not vulnerable, but they do fill up your log files. Here are a few techniquest to prevent that.

One: Apache::CodeRed. Find it at
http://cpan.org/modules/by-module/Apache/ Easy to install, easy to
configure. But needs mod_perl, so if you don’t have that, you’re out of
luck.

Also, I have a hacked version of this, which adds the
address to my firewall deny list. I think I should probably leave that
as an exercise, but basically you have it call a suid script, which
takes an IP address as the argument, and adds a host to your firewall.
Presumably you could do this from a CGI program as well, and invoke that
thus:

Action codered /cgi-bin/code_red.cgi
<LocationMatch "/(default.ida|msdac|root.exe|MSADC|system32)/">
    SetHandler codered
</LocationMatch>

The cgi would look something like:

#!/usr/bin/perl
my $ip = $ENV{REMOTE_ADDR};
`/usr/bin/BLOCK $ip`;
print "Content-type: text/htmlnn";
print "bye, now.";

This will get rid of error log entries, as it will be a valid URL. This
is probably my most recommended approach, unless you want to use
Apache::CodeRed, which also sends email to the domain contacts and ISP
contacts, which is perhaps the best thing to do, but generates a lot of
bounce messages.

Note that even if you don’t add them to your firewall, the above script can be used, minus lines 2 and 3, to eliminate the error messages. And, in conjunction with the “don’t log” recipe below, can remove the problem.

Two: Conditional logging. See tutorial at
http://httpd.apache.org/docs/logs.html#conditional or, for the recipe
version, you need the following:

SetEnvIf REQUEST_URI "default.ida" dont-log
CustomLog logs/access_log combined env=!dont-log

As noted previously, this only covers the access log. The error log is
trickier. One way to handle this is to actually redirect these requests
to a virtual host, with a /dev/null’ed error log. That is how I handled
it before I started firewalling them.

However, this, in conjunction with the recommended CGI program will
eliminate all log entries other than the initial access to the CGI
program, which can also be eliminated if you use the conditional logging
trick.

Note two things about the firewall thing. If you have a busy site, this
is *NOT* recommended, as it will cause your firewall list to grow to an
absurd size. I’m doing this on a home dsl account. Two, if you firewall
them, you’ll get one entry in the error log, perhaps, but no more. There
will be log entries in your firewall log, probably. These are far more
satisfying. Reset your firewall deny list periodically.


Follow-up: Ken Coar notes that you should also check out EarlyBird.

Surreal tech support situation

One of my customers hosts their web site on a Mindspring server, which was bought by Earthlink at some point. The site is running on Apache. The customer had me set up password authentication for a subdirectory, and it was necessary for me to do this with an .htaccess file, which was easy enough. However, since ServerName is apparently set incorrectly in the configuration, they were having the problem described in the FAQ, where you get asked for your password twice, and end up on a hostname that is not what you typed in.

I called EarthLink, and talked with two different support reps before I could get someone that even acknowledged that the problem was happening – the first guy simply would not admit that it was happening. I explained the problem to him (the second guy), told him how to solve the problem, and gave him the URL for the FAQ where it is described. (http://httpd.apache.org/docs/misc/FAQ.html#prompted-twice) After putting me on hold for a lengthy period of time, apparently talking to other experts, he came back and told me that the problem was beyond their expertise to deal with. He encouraged me to read the .htaccess file tutorial on the Apache web site at apache.org. (http://httpd.apache.org/docs/howto/htaccess.html)

Now, for those of you who don’t already know, the reason that this was so very surreal is that I wrote the .htaccess tutorial on the Apache web site. I’m pretty sure that the tech support guy did not believe me when I told him this, but, honest, I really did. And, of course, I’m no closer to having a solution to the problem, because it’s something that has to be done in the main configuration file. ServerName is set incorrectly, and I would need access to the main server config file to fix that, or to set UseCanonicalName off, which is the other recommended solution.

Hopefully, I’ll get someone on the phone next week that believes me, and is willing to implement the recommended solution.

Apache Web Server Administration, by Charles Aulds

Linux Apache Web Server Administration
Charles Aulds
Craig Hunt Linux Library
Sybex Press

Well, I tried to be very critical of this book, because, after all, I want you to buy my book. But it really is very good.

It has thorough converage of all important topics. I found a number of places where information was wrong, but most of these were probably attributable to typesetting errors, rather than author errors. Missing parentheses, for example.

The examples were, for the most part, excellent, with good supporting explantions. Diagrams were good too – not gratuitous, but actually useful in most cases.

If I’m going to complain about something, it would be that there is no clear distinction made of when he’s talking about 1.3, and when 2.0. Or is it all 2.0? I’m really not sure. Some of it appears to be 1.3 specific, but other places he’s very clearly talking about 2.0, although this is not mentioned in the text, and might not be clear to other folks.

Overall, recommended and thorough.

(The book was given to me by the publisher, but I did not receive any other incentive to say nice things about it.)

Apache::VhostDB, sort of

I wanted to write a mod_perl handler that would read vhost configurations out of a database. However, it made more sense, at least to get something working quickly, do to this as a <Perl> section in the configuration file

I guess this could be done as a mod_perl handler instead, and I hope to eventually do it that way (mostly as an exercise, actually) but here it is the way I have it working:

#
#
# create table vhosts
#   (ID  int(11) not null auto_increment,
#    servername  varchar(255),
#    serveralias  varchar(255),
#    docroot      varchar(255),
#    scriptalias  varchar(255),
#    primary key (ID)
#   )
#
#  Note: serveralias can be a space-separated list. Change the field to
#  a text field if you have more than 255 characters of aliases.
#        scriptalas should have a trailing slash
#

<Perl>

use DBI;

my $db       = 'DBI:mysql:vhosts';
my $login    = 'www';
my $password = 'www';

my $dbh = DBI->connect( $db, $login, $password );
my $sth = $dbh->prepare( "SELECT servername, serveralias,
                                 docroot, scriptalias
                            FROM vhosts " );
$sth->execute;
$sth->bind_columns( my ( $servername, $serveralias, 
                          $docroot, $scriptalias ) );
while ( $sth->fetch ) {
    push @{$VirtualHost{'*'}},  {
        ServerName   => $servername,
        ServerAlias  => $serveralias,
        DocumentRoot => $docroot,
        ScriptAlias  => "/cgi-bin/ $scriptalias",
    };
}
$sth->finish;
$dbh->disconnect;

</Perl>

This goes in httpd.conf, and requires mod_perl. And, of course, you can add additional fields if you need them, like ErrorLog and CustomLog.

We both appear to be misunderstood

Hacking Log 2.0

Well, Andy, I seem to have been just as misunderstood as you, and I humbly apologize for appearing to take pot-shots at you. I really did not mean to offend, either by my comments here, or my comments on the mailing list.

You have good ideas, and people are probably overly anxious to criticize, when they could spend that time making constructive contributions. And, without any sarcasm, I admire your passion, your drive, and your obvious desire to get stuff done. It seems that too many of us have lost that over the years.

What I, personally, took umbrage at, was the implication that the processes put in place were there purely to slow down the wheels of progress. You say that you did not intend that implication, and I accept that, and withdraw my comments, with apologies for accusing you of those ideas.

I cannot take up on your offer to fill in those documents and processes, because, clearly, I understand them even less than you do. HTTPd is a world apart from the exciting bleeding-edge projects that go on in the rest of the ASF, and many of us are just as happy it is that way. If nothing else, it makes the books sell better.

I’m sorry I came across as being critical of you personally, or of your obvious passion for the projects that you are part of. As I tried to express on the mailing list, when I ask “why the heck are things the way they are”, I am usually genuinely asking that question, not saying “you are a bad and evil person for making things that way.”

And, just so I’m not disingenuosly hiding behind an alias, I am the guy in the picture there.

The Umbrage Industry

I heard the term “The Umbrage Industry” used recently, and now I can’t recall where that was. If you’re not familiar with the term Umbrage, it means, to put it simply, being offended. We, the people of the United States of America, have perfected the art of umbrage. We manage to get offended at anything, and we manage to see offence taken by people who are merely commenting.

I probably should not mention any names. You probably either know who I’m talking about, or you don’t. Dude, lighten up. If you can’t take a little constructive criticism, then don’t post your ideas in public places where the whole world can see them. Nobody is calling you a sh*thead, as you claim. And, unless this is something that is unique to your little corner of things, which, after all, came out of a big organization into a little one, not the other way around, nobody is abandoning trust.

You seem like a nice guy. I enjoyed meeting you, and I enjoyed talking to you, but you’ve got to quit acting like every issue is a matter of Good vs Evil, with you the sole defender of All That Is Right. It gets a little old. Some things are just matters of opinion, and there’s a chance, however slim it might be, that you’re not always right. Getting offended every time someone disagrees with you is a great way to get a stomach ulcer, but accomplishes precious little else.


Followups:

The phrase was actually in a piece in Newsweek (or was it Time) that my Dad read to us on Christmas, about the ACLU furur surrounding Christmas. Here are some relevant links:

http://reason.com/0212/fe.tc.e.shtml

http://www.jaycaruso.com/archives/001327.html