From 59983d4722c1efd08ea79dcd1932fe72b78ecba7 Mon Sep 17 00:00:00 2001
From: dgaudet
- $Revision: 1.72 $ ($Date: 1997/06/20 17:17:23 $)
+ $Revision: 1.73 $ ($Date: 1997/06/21 18:56:36 $)
The latest version of this FAQ is always available from the main
@@ -131,6 +131,8 @@
Apache Server Frequently Asked Questions
+ On FreeBSD 2.2 and older FD_SETSIZE, which limits the number of open + files on the system, is limted to 256. This can limit the number of + virtual hosts you are using; especially if they all use different log + files. Increasing this limit (and recompiling apache) is not enough + (As it is on some platforms, such as Solaris), as you also will have + to recompile libc with the changed setting. +
++ On FreeBSD 3.0 the default is 1024, so the problem is lessened. +
+struct iovec
" when compiling under Linux?
+ of "struct iovec
" when
+ compiling under Linux?
This is a conflict between your C library includes and your kernel @@ -1584,6 +1614,90 @@
+ Under normal circumstances, the apache access control modules will + pass unrecognized userids on to the next access control module in + line. Only if the userid is recognized, the password is validated + (or not) will it give the usual success or authentification failed + messages. +
++ However if the last access module in line 'declines' the validation + request (because it has never heard of the userid or because it is not + configured) the http_request handler will give one of the following, + confusing, errors: +
check access
+ check user. No user file?
+ check access. No groups file?
+
+ The solution is to ensure that at least the last module is authoritative
+ and CONFIGURED. By default mod_auth
is authoritative
+ and will give an OK/Denied, but only if it is configured with the
+ proper AuthUserFile. Likewise if a valid group is required. (Remember
+ that the modules are processed in the reverse order they appear in
+ your compile-time Configuration file.)
+
+ A typical situation for this error is when you are using the + mod_auth_dbm, mod_auth_msql, mod_auth_mysql, mod_auth_anon or + mod_auth_cookie on their own. These are by default not + authoritative, and this will pass the buck on to the (non-existent) next + authentification module when the user ID is not in their respective + database. Just add the appropriate 'XXXAuthoritative yes' line to + the configuration. +
++ In general it is a good idea (though not terribly efficient) to have the + file based mod_auth a module of last resort. This allows you to access + the web server with a few special passwords even if the databases are + down or corrupted. This does cost a file-open/seek/close for each + request in a protected area. +
++ Some organizations feel very strongly about keeping the authentification + information on a different machine than the webserver. With the + mod_auth_msql, mod_auth_mysql and other SQL modules connecting to + (R)DBMses this is quite well possible. Just configure an explicit host + to contact. +
++ Be aware that with mSQL and Oracle, opening and closing these database + connections is very expensive and time consuming. You might want to + look at the code in the auth_modules and play with the compile time + flags to alleviate this somewhat; if your RDBMS licences alows for it. +
++ You have probably configured the Host by specificing a FQHN, + and thus the libmsql will use a full blown tcp/ip socket to talk to + the database, rather than a fast internal device. Both the libmsql, + the mSQL faq and the mod_auth_msql documentation warn you about this. If + you have to use different hosts, check out the mod_auth_msql code for + some compile time flags which might, or might not suit you. +
+