一个高频率的HTTP服务监控Shell Script

Nginx/Apache之类的长期运行,无法保证在遇到各种突发情况进程不会死掉。如果这时候又出门在外,一时间无法操作,那网站岂不是要宕机数个小时?

明显我无法接受这事情。于是一个简简单单的监控HTTP服务的Shell Script就出来了。

真的简简单单。

可见我并没有采用cron功能,毕竟这东西正常情况最低频率只能一分钟了。

restart那个function是http服务不正常后执行的,可以自行增添,删减,替换。sleep后面跟着的是秒数,在这里简单理解成监控频率吧。wget处,-t参数指的是尝试次数,这里我写了一次。

执行方式:

其中的/root/monitor指的是该Shell Script所存放的路径。记得要先赋予当前用户对该文件的执行权限。

可以添加到/etc/rc.local里面实现系统启动自动执行:

 

终止:

其中grep后面跟着的是你Shell Script的文件名。

有了这东西,出门在外,至少能安心一点了。

Apache:只有访客IP的日志格式

前一篇文章:Nginx日志配合iptables自动封禁IP,提供了一个nginx只有访客IP的日志格式。

这里也顺便提供一个Apache的只有访客IP的日志格式:

把上面的一行代码放到apache的配置文件中去。

然后到站点配置文件中添加:

${APACHE_LOG_DIR}改成存放日志的路径。

配合前一篇文章的Shell Script,即可实现防CC。

实现DirectAdmin使用PHP-CLI模式的站点独立用户与查看各用户资源占用情况

用过DirectAdmin的都知道,CLI是个坑爹货:网站目录非rwxrwxrwx(777)权限无法写入,无法查看是哪个用户占用较多的资源,甚至无法正常使用opcode cache的PHP组件。

Wordpress

我们来研究下DirectAdmin的站点的配置文件:

关键,就在SuexecUserGroup这里,这里定义了站点的执行PHP脚本时所使用的用户身份,这样可以给不同网站的目录不同的所有者,且无需再特意给某些文件设置rwxrwxrwx(777)权限。

然而,这个东西在CGI模式下工作正常,而CLI却不正常。貌似mod_ruid2.c是SuPHP才有的吧?无mod_ruid2.c。Apache自然就忽略掉SuexecUserGroup的内容。

找到问题所在,要解决,就简单得多了。找个CLI上能实现类似功能的模块给Apache加上去就行。

看过我的LVAMP的介绍的,都知道,能实现站点独立用户,而且是CLI模式下实现的。其实真相只有一个——mpm-itk。

由于mpm-itk模块没提供2.2下能使用apxs编译的文件,因此添加有点麻烦。我这里写了一个Shell Script:

先下载:

然后运行:

执行完后,你会看到如下信息:

md5

那个是集成了mpm-itk源码的apache的源码的TGZ的MD5值。因为DirectAdmin的进行编译的Shell Script会自动验证所有源码包的MD5值,不一样就会帮你重新下载,所以就要修改一下DirectAdmin所记录的Apache的MD5值。

修改/usr/local/directadmin/custombuild/versions.txt:

在第六行(一般都是第六行),也就是apache2.2:2.2.24(一般都是2.2.24吧)的那一行,把冒号后面的MD5改成执行mpm-itk.sh后所显示的MD5值:

Versions

 

确认无误后,保存(用vim的话:wq)。

开始编译吧:

这个看你服务器配置了,一般十分钟左右吧……

顺利完成后,还有Apache的站点配置文件的模板要修改,不过文件有点多,直接执行这个Shell Script就好了:

最后在“服务监控”那,重启Apache(也就是httpd)。

再次测试安装Wordpress,已经可以成功写入文件了:

写入成功

 

在top那,httpd进程的执行身份不再是清一色的apache了:

TOP

使用Varnish Cache时,让Nginx获取访客真实IP

之前发表过一篇文章:Varnish(前)+Nginx(中)时,让Apache(后)获取用户真实IP(多重代理)

该方法能成功解决使用或者不使用CDN时,在Varnish前端,Nginx中端,Apache解析PHP文件的情况下让Apache获取访客真实IP。因为当时主要是利用Nginx进行缓存,没使用其他功能,旧没让Nginx也获取访客真实的IP。

其中Varnish处理XFF的关键代码:

也就是把客户的IP赋值给XFF。那样后端处理就方便多了。

昨天在为一台Varnish+Nginx+Apache的服务器添加并测试防轻量级CC的功能,使用的Nginx模块是limit_req。虽然访问网站时,能获取访客的正常IP,但是Nginx得到的却是Varnish所在的服务器的IP。

测试时发现,由于limit_req模块是在Nginx上的,那样受到CC攻击的话,Nginx就会误判断是Varnish服务器的IP发出的请求,就会Ban掉Varnish服务器的IP,再次遇到Varnish的IP时,就会返回403……

403

 

尝试了Nginx的realip_module,发现无任何效果。

于是在另一台空闲的VPS上安装了Ubuntu 12.04,安装了Varnish,Nginx,PHP5-FPM进行测试。

研究了下Varnish和Nginx的配置,于是写了和PHP程序,查看XFF等信息:

测试后发现,REMOTE_ADDR一直都是Varnish所在的服务器的IP,而limit_req获取的正是REMOTE_ADDR的内容,那就是Ban Varnish的IP的原因了。由于Varnish那设置了HTTP_X_FORWARDED_FOR的内容舍弃原有内容(例如CDN服务器传来的),并且只含有客户IP,因此该项正常且不会影响REMOTE_ADDR。X-Real-ip这项内容是空白的,使用realip_module时,会使用到real_ip_header X-Real-IP这代码,大概是告诉服务器X-Real-IP才是客户真正的IP吧。

这下目标明确,要么搞定REMOTE_ADDR的,要么让real_ip_header X-Real-IP的real_ip_header获取真实的IP。

在Varnish那尝试了几次把客户的IP赋值给REMOTE_ADDR,使用或者不使用CDN时,REMOTE_ADDR就出问题了,要么是客户IP,要么CDN服务器的IP。

想了想,既然Nginx的real_ip_header能让Nginx知道访客真实IP,而HTTP_X_FORWARDED_FOR只有访客IP,把HTTP_X_FORWARDED_FOR的内容赋值给real_ip_header不就可以了么?

于是在删除原来所有与real_ip_header有关的代码,在Nginx的网站配置的server层(注意是server不是location)加入如下代码:

果然立竿见影,再次访问那个PHP文件,不管前面有没有上CDN,REMOTE_ADDR都与XFF的内容一模一样,也就是说,Nginx能获取到访客真实IP了。

把刚刚的成果帮到LANVMP的服务器上,在本机上狂F5,返回403,这是预料之中的事情,关键是,别的访客是不是200。于是再次打开17ce进行检查,非常好,全部都是200状态:

200

 

虽然解决该问题花了很多时间去折腾,不过能完美解决,也值得了……