第6节. 多虚拟主机实现

目录访问的别名

别名在welcome.conf里也见过的，上一篇将/.noindex.html的时候就遇到过👇

开始实验

mkdir /app/forum
echo 'thisi is /app/forum/' > /app/forum/index.html

用户通过 curl 192.168.126.130/bbs/ 访问到/app/forum/

当然你说用跳转，没必要，这里用alias别名

当你还还说用软连接，没必要，这用别名

光写别名还不行，👆还需要补上别名的那个目标地址的访问权限。

问题来了①我待会使用curl 192.168.126.130/bbs/去访问，/bbs这个文件夹我感觉不用存在，感觉正确。

②/app/forum在os层面也是需要apache可读的。

总结，页面URL里的路径不一定在DocumentRoot下

curl http://192.168.126.130/dir100，实际上就是打开dir100/index.html页面

①这个dir100文件夹确实在DocumentRoot下，且apache配置文件里有给到访问权限。

②软连接，不过软连接所在的路径应该也需要在配置文件里给到访问权限

③别名，就是上文的alias，这个种dir100文件夹都无需创建。

④跳转应该也算一个，具体见上一篇文章。

基于用户名密码方式控制访问

之前上一篇讲了基于源IP地址来控制访问已经实现了，这里接着讲基于用户名密码

要支持用户名密码方式控制访问，需要确认开启auth_basic模块，当然默认就开启了

要实现的目标：用户访问页面的时候，弹出对话框让其输入用户名密码。

cd /data/www
mkdir admin
echo 'this is /data/www/admin/index.html ...' > admin/index.html

需求：访问主站点无需验证，访问admin/index.html的时候要验证。

比如admin里放的是后台管理的页面，所以需要验证才能访问。

而用户名密码肯定不是系统的用户，而是httpd服务的，这种用户就称之为虚拟用户。不是真实的OS的用户。

这种虚拟用户，在不同的服务里都存在，除了这里的HTTP，还有FTP，等，都是服务自身的用户认证，无关于系统用户。

使用htpasswd来创建http的用户名密码，第一次敲这个命令的时候需要-c指定存放用户名密码的文件的。后续不能使用-c，否则原来的文件就被覆盖了。

由于http页面认证的用户名密码也算是一种配置，所以就放到/etc/httpd/conf.d/配置文件路径下。

找出下图👇错误之处

当然第二次别加-c就对了，然后 ① .httpuser前面的.就是好习惯，用户名密码文件用隐藏的就很不错

②就是交互式的密码2次就很不爽，找一下👇

好创建三个用户吧，重新来一遍

htpasswd -c .httpuser user1
   ...  输入密码
   ...  再次输入密码
htpasswd .httpuser user2
   ...  输入密码
   ...  再次输入密码
echo 'cisco' | htpasswd -i .httpuser user3  # 非交互式类似于echo 'cisco' | passwd --stdin user1

果然和passwd很像，同样也加了盐，所以一样的密码，hash值就不一样了👆。apr1可能是类似哈希算法的类型。后面一段$xxxxx$应该就是盐，$分割除了3段，最后一段就是加了盐一起的哈希结果。

这样用户名密码就有了，下面就是在配置文件里写上调用验证，然后到指定的文件认证就行了。

使用.httpuser密码文件的方法1：写到配置文件

主站无需认证👇

admin路径需要认证

上图没有体现出来AuthName "xxxxx" 内容。估计现在没几个浏览器支持这种显示了。

只有输入Require user 里指定的 admin用户名密码才行

👆上图一共3条记录，前两条是弹窗用户名密码输错了的记录401就是未授权的意思，第三条是正确的用户名的记录而且在记录的开头有显示具体的用户名。

另外curl也支持输入用户名密码的方式，不过就不是交互式的了👇

针对 .httpuser里的所有用户都可以访问这个文件夹

使用.httpuser密码文件的方法2：.htaccess

进一步复习下上一篇的.htaccess文件，就是上述配置可以移到这个文件里

先去配置文件里允许.htaccess覆盖，当然这里选择仅覆盖authconfig就是认证相关的；

然后再将原来配置文件里的4行配置删除，配置到访问路径--也就是需要认证文件夹下

上图修正下，既然已经在这个路径下了，肯定就不需要写Directory了，

修改这些路径下的文件，无需重启服务，验证OK👇

用户组授权的配置

上图👆有错误，httpd -t也检查不出来；①漏掉了AuthUserfile XXXX 路径指定；②随后一行少了group参数。

修改👇

验证效果，符合按组授权👇

前面就介绍了http的访问控制里的基于IP和基于用户名密码的控制，下面学习一下两种方式的选择组合

远程客户端IP和用户验证的控制

浅测一下👇

1、首先我打算把配置都写道页面资源的路径下的.htaccess里

2、于是我就要去到配置文件里去写上"允许覆盖"的参数

3、然后去页面资源路径下编辑.htaccess文件

有点问题，就是Satisfy All没有生效！没有做到双重验证。就是输入用户名后就能访问了，理论上是要备ip 禁止访问的。

这里就会担心这个.htaccess里是否可以这么写，查查官网发现.htaccess支持Satisfy All的

context的意思就是配置在哪里，

不过写法有点变化

IP控制用的是Allow，自然有deny。

然后呢发现

然后发现

结论：

①all确实是用户认证 + IP acl 都要满足；any就是任一个满足就行。

②原来那套配置\XXXXX\</RequireAll> 在这里貌似不行。

③尝试写一个白名单出来

OK~

实现用户家目录的http共享也就是web访问

同样要支持家目录的web访问，要有模块预加载

关于模块加载，见前文👇

下面就是将用户的家目录分享出来

修改权限也没用

恢复原来的权限700👆后继续实验👇

待会使用这个ming1的家目录

找到配置文件userdir.conf

修改对应内容

修改如下

这样就①开启了userdir的共享；②家目录共享不是说所有文件，而是要指定家目录下的某个文件夹共享，如上图的public_html共享。

重启服务后，浏览器访问http://192.168.126.130/~ming/即可

这里要记得修改/home/ming1的权限，只要通过facl给到apache就行了，因为用户访问文件夹，其实是通过httpd服务进程区访问的，而httpd都是apache用户运行的。

修改权限

给了apache进入ming1家目录的权限就行了

同样注意一点就是facl设置以后的ll

注意必须是/~userDir/的写法

加一个验证

👇注意：缓冲会导致弹不出验证窗口：①常规浏览器需要清缓存才能弹；②无痕需要关闭所有无痕再打开新的无痕才能保证没有缓存；如果有一个无痕没关，则缓存还在。

其实写一个.htaccess就要有一个习惯思维--就是是否可以写进去，如果不行就写道directory里。啥意思

上下文可以写的地方有👇

像有的配置就写在别的地方👇

再一个

这样试试看

结果也是正常的👇并没有说上面的授权全放就全放了，下面没有不起作用。挺好~

要实现这种哪哪都生效的效果，是不是代码里 ①将所有配置合并②找出最严格的配置③类似rib里的最长匹配。

ServerSignatrue

和结合serverToken一起梳理知识点

浅测一下

再删掉.htacess做一下放心对比动作

我感觉.htaccess挺好，因为它不是配置文件，无需重启服务就能生效；但是它又能做配置文件里的配置，就很香了。

status页面，可以用来做网站的监控

依赖于这个模块👇

干嘛的呢，就是获取apache的工作状态，默认关闭的。

又可以塞到.htaccess里了，哈哈，开心

当然，你要用directory一样的效果，不过要配置，同样DocumentRoot下的.htaccess或者配置文件里配置：

这倒是个看MPM的方法，默认果然是prefork。

理解下上图👆

__.................这些表示的是进程状态，很多下划线和...说明进程太多了

_ 就是等待连接

. 就是打开slot但是没有线程来处理

发现一个问题，得到3种status的配置方法

就是setHandler server-status，这个写在两次，

①配置文件里的只能是DocumentRoot下带/status访问，就是http://192.168.126.130/status，也不影响http://192.168.126.130/，这就是index.html的访问不受影响。

也不能写成"/www/data/status"，不会生效，所以只能放到documentRoot下来访问。

②写道url路径文件夹下，但这种写法，就是把index.html给覆盖了，就是你访问http://192.168.126.130/~ming/ 后面带或者不带或随便写都是打开的status页面了

③其实可以这么玩

去掉配置文件里的相关配置

记得重启服务，验证一下

然后在DocumentRoot下新建一个status文件夹，然后进去编辑.htaccess，里面写一个setHandler

这样这个status文件夹里所有的页面统统不生效，你也无需创建其他任何页面，该文件夹就一个作用--setHandler server-status，显示服务器状态。

这样也自然也不会影响documentRoot的index.html

然后针对这个status页面限定只能特定IP查看

写到配置文件里也行

重启服务后，测试

虚拟主机

host就是你访问的域名/IP，记录在报文的host字段里了，该字段属于head，http的报文头。这是client发送请求的时候携带的，当server收到一看就知道了你访问的是啥了，所以这就是LB的转发最佳实践，而不是基于desti-端口也不是基于dest-IP。

之前用telnet 测试写过host👇，那会host是随便写的，因为没有涉及server检查host做负载均衡的机制，也就是没有做这里的虚拟主机来依据host转发的技术。

下面开始实验

首先、规划三个网站，简单就是三个文件夹页面就行了。

上图👆有错误，index.thml改成index.html才行。

虚拟主机-基于三个不同的des ip

然后编写配置文件，documentRoot、directory、access_log独立开来、virtualhost IP

重启后，access_log_asite文件就生成了，然后在写2个

通过域名访问简单加个host

就可以了👇

但是时间太慢了

浅查一下：结果一查就查了2小时，这里直接回头来写结论，load确实高，但不是load的问题，是allow from any，不用用any的原因，排障过程往下慢慢看。

负载太高了，如何判断高呢，依据如下👇，所以上图👆4 C，load 不能超过12。然后load 三个值分别是1分钟、5分、10分钟的均值。

解决下，注释掉进程开启过多的配置，只是对于我这个pc的workstation的VM来讲太多了

等一会，等load降下来就可以测试看是否变快了

是快一点，但是也要4s呢，奇怪了不应该啊

难道虚拟主机就是慢？

昨天也没有这么卡啊，同样的👇cli，估计笔记卡了，但是笔记本资源利用也就45%内存啊。其他都很低啊。

curl www.b.com 卡在那的时候，同时看看I/O也没变化，也不卡啊

浏览器打开，就是用无痕，也不卡，奇怪了，之前负载高的时候浏览器就不卡

TMD curl卡浏览器不卡是啥什么鬼？

将除了虚拟主机以外的所有配置全部注释掉，发现竟然好了--速度快了

只要再打开注释，就会变慢，👇

定位具体问题出在哪？

发现只要这一段打开，就会卡

👆上图结论不一定对，进一步对比，取消上图的框选的部分的注释，然后注释掉虚拟主机部分，发现依然有2-4s的情况

出现频次也不低，发现还是👇这部分问题，

这部分问题不一定是看到的配置出了问题，去/data/www下面ls -a看到

删掉后继续测试，返现速度一直都很快，故障消失了

再补回去，故障又出现了

这里还不是白名单写法，如果是白名单写法应该是 deny from all，这样就是拒绝所有，放行了126.1。

而deny from any拒绝任一，就很不符合逻辑。但是从效果上来讲，就是除了126.1，其他curl都TM会卡。

修改成

黑白名单的坑-1，不能用any：测试过程在上下段落，这里是结论

结论，就是.htaccess的错误的写法(deny from any)导致，这会频繁的出现访问卡顿的情况。就用allow from all，deny from all ，只用all字样就行了。

然后研究下黑白名单

白名单写法，测试有效

但是黑名单失败了，

查资料

图上框出来的还是原因，没框出来的，First, all Deny directives are evaluated; if any match, the request is denied unless it also matches an Allow directive.

这才是原因，所以

直接看表格

https://httpd.apache.org/docs/2.4/mod/mod_access_compat.html#allow

所以这样的👇配置最大的关键点也是疏忽点就是，Match both Allow & Deny 在默认的机制(Deny,Allow)下是放行的，分析下图：whiteList有效是因为126.1和126.131是both命令allow和deny all所以allow，其他没写的Only match deny所以deny了。而下图的黑名单写法192.168.126是同时命中了deny和allow all所以就放行了，没有做到deny 具体IP的效果。

上图黑名单失败，修改一下，去掉deny就行了，这样依然是默认的deny,allow机制，但是deny的126段only在deny语句里，没有说 no match也没有both match。

黑白名单的坑-2，默认顺序(Default: Order Deny,Allow)黑白名单写法，这里是结论，过程见上文

黑名单简单，拒绝什么就些什么，不要写allow all字样！写了就是both match 全放了。
deny from 192.168.126.1

白名单写法
allow from 192.168.126.1
deny from all        # 这里底层逻辑与众不同，126.1是 both match，也就是同时满足allow和deny语句的，所以both match是allow放行的，其他没写的IP，就是only match deny的，是拒绝的。

然后statisfy是针对源IP和用户名的一个机制，all就是两种因素认证，any就是(源IP或者用户名密码)任一满足就行。