Category list

B.5 Fixing Build-Time Error Messages

B.5.1 __inet Symbols

If you have installed BIND-8, then this is normally due to a conflict between your include files and your libraries. BIND-8 installs its include files and libraries in /usr/local/include/ and /usr/local/lib/ , while the resolver that comes with your system is probably installed in /usr/include/ and /usr/lib/ .

If your system uses the header files in /usr/local/include/ before those in /usr/include/ but you do not use the new resolver library, then the two versions will conflict. To resolve this, you can either make sure you use the include files and libraries that came with your system, or make sure to use the new include files and libraries.

If you're using Apache 2.0 or later, or Apache 1.3 with the APACI build script, you can make changes to the library search lists by defining them on the ./configure command line:

%

LIBS=-lbind ./configure


...

If you're using Apache 1.3 or earlier and controlling the build process by editing the Configuration file directly, just add -lbind to the EXTRA_LDFLAGS line in the file.

After making the appropriate change to your build configuration process, Apache should build with the correct library.

Apache Versions 1.2 and earlier use EXTRA_LFLAGS in the Configuration file instead.

As of BIND 8.1.1, the bind libraries and files are installed under /usr/local/bind by default, so you should not run into this problem. Should you want to use the bind resolvers , you'll have to add the following to the respective lines:

For Apache 1.3 with APACI, or 2.0 and later:

%

CFLAGS=-I/usr/local/bin/include \

>

LDFLAGS=/usr/local/bind/lib LIBS=-lbind \

>

./configure


...

For Apache 1.2 or 1.3 with direct editing of Configuration , add/change the following lines in the file:
```
EXTRA_CFLAGS=-I/usr/local/bind/include
EXTRA_LDFLAGS=-L/usr/local/bind/lib
EXTRA_LIBS=-lbind
```

B.6 Getting Server-Side Includes to Work

The solution is to make sure that Options Includes is turned on and that either XBitHack is turned On , or that you have the appropriate AddHandler directives set on the file type that you are using.

As discussed in Recipe 8.8, there are a number of ways to enable SSI. If the unparsed SSI directives are appearing in the HTML when the page is loaded, this is a clear indication that SSI execution is not enabled for the document in question.

If the server has difficulty parsing an SSI directive, it will substitute the phrases "An error occurred while processing this directive" in its place in the response. If this happens, the cause of the problem should be listed in the server's error log. See also Recipe 8.12.

B.7 Debugging Rewrites That Result in "Not Found" Errors

If your RewriteRule directives keep resulting in 404 Not Found error pages, add the PT (PassThrough) flag to the RewriteRule line. Without this flag, Apache won't process a lot of other factors that might apply, such as Alias settings.

You can verify that this is the cause of your problem by cranking the mod_rewrite logging level up to 9 and seeing that the entries relating to the RewriteRule mention something about prefixes with document_root:

RewriteLog logs/rewrite-log
RewriteLogLevel 9

%

tail logs/rewrite_log


ip-address

- - [

date

] [

reqid

] (2) prefixed with document_root to /usr/local/apache/htdocs/robots.text

ip-address

- - [

date

] [

reqid

] (1) go-ahead with /usr/local/apache/htdocs/robots.text [OK]

Don't forget to turn off the RewriteLog directive, or possibly just turn down the logging level, after you've done your checking! Otherwise your disk space may disappear like the snows of yesteryear.

Without the PT flag, mod_rewrite assumes that any rewriting it does will be the last URL manipulation the server needs to do for the request. Since mod_rewrite directives are handled very early in request processing, this can mean that Alias , ScriptAlias , and other URL manipulations may not get executed. Specifying the flag tells mod_rewrite to not short-circuit processing, but let it continue as usual.