a2enmod, a2dismod, a2ensite, a2dissite
a2enmod/a2dismod 启用／禁用模块
a2ensite/a2dissite 启用／禁用虚拟站点
实际上，另外三个文件只是一个指向 a2enmod 的软链接。
Debian与Ubuntu上自带的Apache配置文件，是有自己独特的组织风格的（SUSE也独特），于是想应该有自己的“独特”的管理方式。man -k apache了一下，发现这四个“工具”。
用法非常简单，不跟参数运行，有会“向导”，也可直接跟模块名，或者site名。
apr和apr-util包含在Apache httpd的发行源代码中，并且在绝大多数情况下使用都不会出现问题。当然，如果apr或apr-util的1.0或1.1版本已经安装在你的系统中了，则必须将你的apr/apr-util升级到1.2版本，或者将httpd单独分开编译。要使用发行源代码中自带的apr/apr-util源代码进行安装，你必须手动完成：
# 编译和安装 apr 1.2
cd srclib/apr
./configure –prefix=/usr/local/apr-httpd/
make
make install
# 编译和安装 apr-util 1.2
cd ../apr-util
./configure –prefix=/usr/local/apr-util-httpd/ –with-apr=/usr/local/apr-httpd/
make
make install
# 配置 httpd
cd ../../
./configure –with-apr=/usr/local/apr-httpd/ –with-apr-util=/usr/local/apr-util-httpd/
通常我们认为Apache的模块分五类：多路处理模块(MPM)，基本模块(Base)，扩展模块(Extension)，实验性模块(Experimental)，第三方模块(External)。
关于各模块的状态详情可以查看手册。第三方模块不包含在发行版中，手册中只标识了四种状态：
| M | 多路处理模块 | 必须有且仅有一个MPM被静态编译到服务器中。 |
|---|---|---|
| B | 基本模块 | 默认包含，必须明确禁用。 |
| E | 扩展模块 | 默认不包含，必须明确启用。 |
| X | 试验模块 | 默认不包含，必须明确启用。 |
Apache 2.2.14 默认被静态编译进httpd的模块：
不可或缺
core.c
http_core.c
mod_so.c
prefork.c（Linux上默认是prefork.c）
mod_authn_file.c
mod_authn_default.c
mod_authz_host.c
mod_authz_groupfile.c
mod_authz_user.c
mod_authz_default.c
mod_auth_basic.c
mod_include.c
mod_filter.c
mod_log_config.c
mod_env.c
mod_setenvif.c
mod_version.c
mod_mime.c
mod_status.c
mod_autoindex.c
mod_asis.c
mod_cgi.c
mod_negotiation.c
mod_dir.c
mod_actions.c
mod_userdir.c
mod_alias.c
[B]mod_auth_basic.c 或
[E]mod_auth_digest.c 加 (2.2.14版时，已经由实验模块转为扩展模块)
[B]mod_authn_file.c 加
[B]mod_authz_user.c
注意！basic加密方式密码是明文传送的，不安全，建议使用digest方式的认证。
[B]mod_authn_default.c
[B]mod_authz_default.c
出于安全考虑，强烈建议加载！
[B]mod_authz_host.c
提供基与主机名、IP地址以及请求特征的访问控制。
[B]mod_log_config.c
[B]mod_alias.c
[B]mod_dir.c
[B]mod_mime.c
[B]mod_setenvif.c
[E]mod_rewrite.c
[E]mod_deflate.c
[E]mod_expires.c
[E]mod_headers.c
1. ./configure --prefix=/opt/httpd-2.2.14 --with-mpm=prefork --enable-mods-shared=all LDFLAGS='-s'
2. ./configure --prefix=/opt/httpd-2.2.14 --with-mpm=prefork --enable-mods-shared=all --enable-cache --enable-mem-cache --enable-ssl --enable-file-cache --enable-disk-cache --enable-proxy --enable-proxy-http LDFLAGS='-s'
3. ./configure --prefix=/opt/httpd-2.2.14 --with-mpm=prefork --enable-mods-shared=all --enable-dir=static --enable-authz-host=static --enable-auth-basic=static --enable-authn_file=static --enable-authz_user=static --enable-authn-default=static --enable-authz-default=static --enable-setenvif=static --enable-alias=static --enable-log-config=static --enable-deflate=static --enable-rewrite=static --enable-mime=static --enable-expires=static --enable-cache=static --enable-mem-cache=static --enable-headers=shared --enable-disk-cache=shared --enable-file-cache=shared LDFLAGS='-s'
注意：因为Apache的./configure生成的Makefile不支持make install-strip，所以使用 LDFLAGES=’-s’ 来编译被strip的代码。
参考：
深入理解软件包的配置、编译与安装
Apache 2.2 手册-编译与安装
Apache 2.2 手册-动态共享对象支持
Apache 2.2 手册-各模块的简介描述
Apache 2.2 手册-描述模块的术语
Apache 2.2 手册-指令速查
mod_authn_default
该模块是一个失败补救(fallback)模块，它在未正确配置认证模块(比如mod_auth_basic缺失mod_authz_user模块的，语法检查检查不出来)的情况下简单拒绝一切认证信息。起到保护数据的作用。
mod_authz_default
在未正确配置授权支持模块的情况下简单拒绝一切授权请求。同样起到保护数据的作用。
假如没有加载default模块，那么，错误的认证配置，会使服务端产生一个500状态码，默认情况下，会生成一个“The server encountered an internal error or misconfiguration and was unable to complete your request.”的提示，有助于管理员调试。
假如加载了default模块，那么错误的认证配置，会使客户端始终不能通过认证，最终返回一个401状态码。
出于安全考虑，这两个模块在启用认证的情况下，一定要加载！
相信绝大多数人，都是直接对 /etc/security/limits.conf 文件进行的修改，添加类似下面的两行：
* soft nofile 10240
* hard nofile 10240
这样也能达到效果。但是经验告诉我，能在局部修改，就不要动全局——因为我们不好评估全局会对哪些应用造成影响（就修改nofile参数一事来说，目前还没有发现修改全局对系统的明显影响，但是理论上可以肯定，将全局的限制放宽，意味着使系统容易受到“资源耗尽”类的攻击，然而在我的工作经历中，还没有遇到一例类似事故发生过），所以我建议将这些局部性的修改放到各自的启动脚本里。
在apachectl脚本里，有这样的语句：
#
# Set this variable to a command that increases the maximum
# number of file descriptors allowed per child process. This is
# critical for configurations that use many file descriptors,
# such as mass vhosting, or a multithreaded server.
ULIMIT_MAX_FILES=”ulimit -S -n `ulimit -H -n`”
# ——————– ——————–
# |||||||||||||||||||| END CONFIGURATION SECTION ||||||||||||||||||||
# Set the maximum number of file descriptors allowed per child process.
if [ "x$ULIMIT_MAX_FILES" != "x" ] ; then
$ULIMIT_MAX_FILES
fi
所以，我推荐直接修改apachectl，在ULIMIT_MAX_FILES=”ulimit -S -n `ulimit -H -n`” 之前，设定nofile的“硬限制”，如下：
# number of file descriptors allowed per child process. This is
# critical for configurations that use many file descriptors,
# such as mass vhosting, or a multithreaded server.
ulimit -H -n 5000
ULIMIT_MAX_FILES=”ulimit -S -n `ulimit -H -n`”
# ——————– ——————–
# |||||||||||||||||||| END CONFIGURATION SECTION ||||||||||||||||||||
# Set the maximum number of file descriptors allowed per child process.
if [ "x$ULIMIT_MAX_FILES" != "x" ] ; then
$ULIMIT_MAX_FILES
fi
这样修改的好处在于，只有Apache的“nofile”受到影响，不影响其它。
原公司的所有应用的管理脚本中（apachectl、nginxctl），都进行了修改，并且使用”isystem”（自己写的一套脚本、小程序的集合）进行统一管理，以至于到后来，我几乎已经忘掉了这些事情，但是系统仍然运行良好，没有再出过 “too many open files” 的问题。
注意：修改过nofile的hard限制以后，需要先stop，再start，httpd进程的限制才能使用新改的参数。
查看当前运行中的进程的limit信息，可以利用/proc（当前Linux内存为2.6），比如apache的一个进程号是10232：
cat /proc/10232/limits
Apache的认证模型
Apache的认证模块分成三个部分：认证类型模块，认证支持模块，认证授权模块。
认证类型模块(auth)：
mod_auth_basic
mod_auth_digest
认证支持模块(authn)：
mod_authn_alias
mod_authn_anon
mod_authn_file
mod_authn_dbd
mod_authn_dbm
mod_authn_default
mod_authnz_ldap
认证授权模块(authz)：
mod_authnz_ldap
mod_authz_dbm
mod_authz_default
mod_authz_user
mod_authz_groupfile
mod_authz_owner
注意：
mod_authnz_ldap模块即包含认证功能也提供授权功能。mod_authn_alias本身并实现认证功能，但是允许其它认证支持模块以更灵活的方式进行配置。
mod_authz_host 模块提供基于主机名、IP地址、请求特征的访问控制，但并不属于认证支持系统。
一般常用的AuthType 是”Basic/Digest”，这个认证需要用到认证模块mod_auth_basic/mod_auth_digest，和认证支持模块mod_authn_file和认证授权模块mod_authz_user。
就是说，最常用的认证组合方式是：
mod_auth_basic/mod_auth_digest
+
mod_authn_file
+
mod_authz_user
即是说，一个使用认证以及访问控制（支持Order Allow,Deny ,Allow from all这样的指令）Apache系统，至少要用到下面四或者五个模块：
mod_auth_basic/mod_auth_digest
+
mod_authn_file
+
mod_authz_user
+
mod_authz_host
不太熟悉Apache认证的管理员，为了优化Apache占用的内存，往往会注释掉一些用不到的模块，而又因为不明白认证模块之间的关系，而导致认证总是不能成功，而apache（目前我使用的版本：2.2.3）的语法检查检查不出来mod_authz_user模块的缺失，故常常使管理员困惑。
重要提醒：
Basic认证类型不加密来自用户浏览器的密码，因此不应该用于保护敏感数据。对于敏感的数据，应使用Digest方式来进行认证（比较老的浏览器不支持，不过时至今日，应该已经不是问题了）。
参考：http://www.bsdmap.com/UNIX_html/ApacheMenu_zh_CN/howto/auth.html
当前使用的Apache的版本为2.2.3，支持以下使用方式：
apachectl -v
apachectl -V
apachectl -l
apachectl -L
apachectl -S
apachectl -M
apachectl -V
1. 查看Server version。
2. 查看编译时间。
3. APR 及 APR-Util 的版本。
4. 硬件架构/平台（64-bit/32-bit）
5. 查看 Server MPM（Prefort/Worker）
6. 是否支持线程（threaded）
7. 定位 HTTPD_ROOT
8. 定位配置文件
9. ……
apachectl -l
静态编译进httpd程序的模块。比如：
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c
这个命令也可以用来查看 Server MPM，一般情况下，要么是prefork.c，要么是worker.c。
apachectl -L
查看目前Apache支持的指令，其中不包括加载模块后模块支持的指令。
apachectl -L | grep ^[A-Z]
apachectl -S / apachectl -t -D DUMP_VHOSTS
查看Apache下配置的虚拟主机情况。注间这里的“default server”是有特殊作用的。有时候我们需要专门统过调整Vhost配置段的位置或者vhosts配置文件被加载的顺序来调整、设立“default server”。
apachectl -M / apachectl -t -D DUMP_MODULES
查看apache目前配置里加载的模块。
在主配置文件段里添加了
FileETag None
但实际上并不总是有效，原因还没有找到。于是使用下面的方式：
<IfModule mod_headers.c>
header unset Etag
</IfModule>
可行。
使用mod_ssl模块，使Apache可以使用SSL协议加密HTTP协议，用来保护HTTP会话。
最简洁的配置样例：
<VirtualHost _default_:443>
ServerName www.bsdmap.com
DocumentRoot /opt/httpd/htdocs
SSLEngine on
SSLCertificateFile /opt/httpd/conf/ssl/www.bsdmap.com.cert
SSLCertificateKeyFile /opt/httpd/conf/ssl/www.bsdmap.com.key
</VirtualHost>
SSLEngine ON 启动SSL引擎
SSLCertificateFile 指定证书
SSLCertificateKeyFile 指定相关密钥
使用SSL加密分为正式场合，比如网上银行、支付宝等对应用安全要求较高的应用上；另一个为非正试场合，比如自己也可以配置一个SSL的web服务。区别在于，正式场合https应用使用的SSL证书是经过第三方数字签名的，而非正式应用，则是非正式机构或者是自己制作、签名的。
成生密钥对儿：
在创建证书之前，要有一个共公／私有密钥对儿。以www.bsdmap.com为例：
openssl genrsa -des3 -rand file1:file2:file3 -out www.bsdmap.com.key 1024
genrsa：告诉openssl要生成一个RSA的密钥对儿。
des3：表示私钥应该被一个”pass phrase”编码和保护。
rand：给OpenSSL提供任意的、随机的数据以确保生成的密钥是唯一的和不可预知的。这个开关在Windows里没有必要，在Windows下使用其他的方式获得随机数据。
out：保存位置。
1024：密钥位数。
当使用了-des3选项，成生了受“口令”保护的密钥对儿时，启动apache时需要输入口令才能启动。假如不想要每次都输入“口令”（不安全），可以使用不受“口令”保护的密钥，去掉-des3选项即可，也可以使用下面的命令转换一下：
openssl rsa -in www.bsdmap.com.key -out www.bsdmap.com.key.nopassword
显示密钥文件的信息：
openssl rsa -noout -text -in www.bsdmap.com.key
该命令也可用于查看ssh-key的信息，其实质是一样的。
创建一个证书签署请求（正式应用场合）：
正式场合的应用，需要一个经证书颁发机构签署的证书，为此，我们先成生一个证书，提交由第三机构签名认证。使用命令：
openssl req -new -key www.bsdmap.com.key -out www.bsdmap.com.csr
需要填写一些地域、组织机构类的信息。需要特殊说明的是：在一个网站站书里，Common Name (eg, YOUR name)一栏标识完全限定的域名（FQDN），假如此处与以后使用证书的站点名不同，浏览器将发布一个错误，无法访问。
完成之后，证书就存储在www.bsdmap.com.csr里。下面的命令可以显示这个证书的信息：
openssl req -noout -text -in www.bsdmap.com.csr
然后，可以所这个证书签署请求提交给一个CA（证书签署机构）处理。
Verisign和Thawte是两家可以选择的CA：
https://digitalid.verisign.com/server/apacheNotice.htm
https://www.thawte.com/ssl-digital-certificates/buy-ssl-certificates/
创建自签署证书（非正式应用场合）：
非正式的应用，可以自己签署自己的证书：
openssl x509 -req -days 365 -in www.bsdmap.com.csr -signkey www.bsdmap.com.key -out www.bsdmap.com.cert
并且，必须使用：chmod 400 www.bsdmap.com.key 来保护密钥文件。
另一个问题：
貌似SSL不能与基于主机名的虚拟主机一同工作。
有一个协议把一个已有的HTTP连接升级到TLS，但是并不是所有的浏览器支持此项功能（RFC 2817）。
参考：
SSL原理解析
http://www.yesky.com/ServerIndex/77125243130347520/20040426/1791592.shtml
SSL原理解密
http://fanqiang.chinaunix.net/a6/b8/20010608/121000441.html
以下为引用：
我的想法源起于这样一个事情，有一次一个网站的技术总监问我，为什么他们的网站那么慢，要怎么办。当时，我的MSN里Zend总部的工程师正好在线，我就 问他PHP响应比较慢了，怎么办？他当时直接告诉我，数据库问题！肯定是数据库没有优化设计好。所以，我没有给那个技术总监确切的答案了，因为他们的数据 库设计我们是不能涉及的。所以就给了大概的数据库优化的建议。这样的事情屡次发生，我就开始怀疑，为什么Zend总部的工程师每次都跟我 说是数据库的问题呢，难道我们不能从PHP层面来解决这个问题吗？答案是不能！因为PHP目前的运行速度已经是很快了，通过Zend的性能分析也能看到一 个用户的点击，PHP的运行时间只有10%不到，那PHP在干吗？它在等。等数据库的查询结果。这个方面在目前的PHP产品中有了很大 的提高，那就是Caching和网页静态化两个方案。Caching可能大家会比较陌生，但是网也静态化现在连PHP产品的用户都非常清楚了。速度快、容 易被搜索到等等，好处不言而喻。开玩笑地说，现在网站的主页实现网页静态化只需要硬盘足够大。至于Caching就比较复杂些，也是大多数PHPer感到 头疼的地方。甚至于有些人会用C来实现。因为Caching中的数据有效期验证、查找、提取、更新等等都是比较难处理。当然，也有人会用数据库来处理 Caching问题。