一些wordpress插件兼容php7.x后的一些修改

不知算不算手贱,把VPS服务器上的php升级到7.0, 虽然7.x与之前的兼容性是很高的,但移除了一大堆过时用法,而某些老应用仍然在使用。对个人wordpress站点里出现的错误,修正记录如下。全部是插件,wordpress官方程序,是没有问题的。

mysql_escape_string() 函数改为addslashes()

wp-thread-comment插件 wp-content/plugins/wordpress-thread-comment/wp-thread-comment.php  有多处

mysql_* 系列函数在php7里全部移除了,所以建议在所有文件里搜索一下 mysql_query, mysql_escape_, mysql_real_eacape 等函数,如:  grep -r mysql_query /path/to/your/site

split()函数改为explode()

auto-save-image插件 wp-content/plugins/auto-save-image/auto-save-image.php  122行

语法兼容

Configure SMTP插件  wp-content/plugins/configure-smtp/configure-smtp.php  171行,为函数定义添加默认值

public function options_page_description( $localized_heading_text = '' ) {

MySQL服务器设置max_user_connections防止连接耗尽,以提高可用性

问题简述/现象及原因

一台MySQL服务器上,有多个数据库,由不同用户使用,相互之间没有或很少关联性。典型的实例是虚拟主机,或者有N多个小网站的某些低频企业应用。

这种环境下,难免有部分应用的质量不高:

出现效率极低的慢查询 -> 后续请求大量被locked排队 -> MySQL服务实时连接数达到最大连接数限制  ->  无法建立新连接

so, 所有相关应用全部挂掉

应对方案

为防止上述情况发生,要为MySQL配置max_user_connections参数。该参数作用是设置单个用户最大连接数限制。具体设置多少,要根据实际情况再裁定。

需要引起注意的是,这个参数是针对所有用户的限制,所以要考察正常情况下连接数最多的用户。可以使用下面语句实时查询各用户连接数。

select `USER`,COUNT(`USER`) AS CNT from information_schema.PROCESSLIST GROUP BY `USER` ORDER BY CNT DESC;

一个参考数值,将 max_user_connections 设置为正常情况下单用户最大连接数的3-5倍。

max_user_connections参数可以在MySQL运行时动态设置 set global .... 当然,也要同步写到my.ini配置参数里。

方案评估

max_user_connections 是个一刀切的配置参数,好像MySQL不能对每个用户设置连接数,并发查询数,io,cpu占用或其它什么什么的细粒度参数。或许并非一定有效。

与max_connections参数对比

max_connections 是指整个mysql服务器的最大连接数;

max_user_connections 是指每个MySQL用户的最大连接数

MySQL官方文档相关章节

php版本(5.3,5.5,7.0)及运行模式(fast-cgi/fpm,apache模块)之间性能对比测试

php 7.0发布在即,一直以来有传言说php7性能有飞跃,于是做了一个测试。

测试环境

硬件  虚拟机2G内存
OS  CentOS 6.7 (kernel 2.6.32-573.7.1.el6.x86_64)
Web  Apache/2.2.15 (centos 6自带)

php版本选择

5.3.3, CentOS 6自带的版本
5.3.29, 官方5.3分支的最后一个版本,用于跟apache模块做对比
5.6.15,
7.0.0beta3

除了第一个CentOS自带5.3.3是apache模块之外,全部跑在fast-cgi (php-fpm) 模式下,通过apache模块mod_proxy_fcgi整合在apache中(整合方式)。每个版本配置一个虚拟站点,域名分别为 a.dom, b.com... 。

php编译参数

三个自编译版本的编译参数如下(在 /usr/loca 目录下,分别安装到子目录里)

'./configure' '--enable-fpm' '--prefix=/usr/local/php53' '--with-config-file-path=/usr/local/php53/etc' '--with-config-file-scan-dir=/usr/local/php53/etc/php.d' '--enable-exif' '--with-gd' '--with-mysql' '--with-mysqli' '--with-pdo-mysql'

'./configure' '--enable-fpm' '--prefix=/usr/local/php56' '--with-config-file-path=/usr/local/php56/etc' '--with-config-file-scan-dir=/usr/local/php56/etc/php.d' '--enable-exif' '--with-gd' '--with-mysql' '--with-mysqli' '--with-pdo-mysql'

'./configure' '--enable-fpm' '--prefix=/usr/local/php7' '--with-config-file-path=/usr/local/php7/etc' '--with-config-file-scan-dir=/usr/local/php7/etc/php.d' '--enable-exif' '--with-gd' '--with-mysql' '--with-mysqli' '--with-pdo-mysql'

[注] centos自带5.3.3配置参数略,有点长,而且很多模块动态编译成动态加载模块,编译参数里是with-out,所以参数价值不大,故从略。
php7已经移除mysql模块,所以其配置参数里的 --with-mysql 事实上没用,在实际编译中被忽略掉的。

php-fpm配置

php-fpm全部配置成最大20进程,apache也配置成最大20个进程

测试说明

在本机上使用ab测试,减少网络传输的影响,500次连接,并发10,记录 Requests per second(req/s, 以下不再指明),示例

ab -c 10 -n 500 -H "Host: c.dom" http://127.0.0.1/phpinfo.php

[注] 因为使用虚假的域名,所以通过 -H参数指定主机名Host(改host文件也是一样的效果)

测试过程1:phpinfo页面

静态html基准测试,将phpinfo页面的输出保存成html文件,每秒稳定在3000次以上(300并发以下基本上能稳定在3000次,开ab的-k参数的情况下)

(phpinfo页面测试意义其实不大)

版本           次数1       次数2        次数3
---------     --------   --------    ----------
5.3模块:       810         837         774
5.6:          517         635         663
7.0b3:        675         700         638

这里看出php7的性能并不突出,反而apache模块运行效率更高

测试过程2:新安装wordpress文章页

新安装wordpress,其自带的一篇文章页http://127.0.0.1/wordpress/?p=1

版本          次数1        次数2        次数3       次数4
---------    --------    --------    ---------  --------
5.3模块:      7.00        7.06        6.84       6.91
5.6:         7.54        7.55        7.48       4.55
7.0b3:       10.12       10.38       10.14      10.47

[小结]:5.6 较5.3略有增强,但差别很小;但php7较都有显示提高。

测试过程3:wordpress导入一批文章后的文章页

导入一批文章后,该测试里增加php5.3.29的fast-cgi版本

ab -c 10 -n 500 -H "Host: c.dom" http://127.0.0.1/wordpress/?p=6459
版本         次数1      次数2       次数3      次数4      次数5    平均值
---------   ------    -------    --------   -------   -----   -----
5.3模块:     5.76      5.60       5.66       5.64      5.82    5.696
5.3 fpm:    5.86      5.97       5.91       6.11      5.97    5.964
5.6:        6.57      6.62       6.65       7.35      5.49    6.536
7.0b3:      8.73      8.33       9.02       9.00      8.67    8.750

[小结]:延续前面的结果,php7比5.x有30%-50%提升,效果明显。

另外5.3的fastCGI及模块差别可以忽略,似乎不像有人说的fastCGI效率有多高。

php7性能提升幅度,似乎也不像鸟哥Laruence所说的翻倍以上的提升(第45页片子)但30%+的提升,也足够让人欣喜了

测试结论

就前面做的测试来看,php7确实比5.x版本有明显提升,值得在生产环境中部署(暂不考虑兼容性)。然而说前面测试结果来看,

附记*php的后向兼容性

按官方文档所示,php7在语言核心方面,变化几乎忽略。主要是彻底放弃php5.4以来已经声明“过时”的特性。

已知可能有较大影响的是 mysql_* 函数被移除,这就意味着使用mysql_*的一些旧应用将无法在php7上跑!一个可选的解决方案是,使用fastCGI,多php版本共存,迁就这些旧应用。

apache下php版本共存,可以参考CentOS 6.x/apache 2.2下php多版本共存探索(模块及fastcgi)/mod_proxy_fcgi实现

新版本firefox(如ESR 38+/45+)下live http headers扩展重发请求功能异常修正版

[20160803更新] 安装扩展 Live HTTP Headers (clone) 即可. https://addons.mozilla.org/zh-Cn/firefox/addon/live-http-headers-clone/

感谢该clone版作者的贡献,同时也感谢原版作者的贡献!

------------------------ 下面的文章内容已经过时,仅供参考-----------------

live http headers扩展是一个神器,彪悍简洁好用。然而似乎用户并不那么多,导致维人员看上去并不那么上心,出过几次无法正常使用的bug。本文是本人探索积累下来的经验。

firefox 38左右某版本下解决方案

[20151105]

firefox下的live http headers扩展的功能就不说了,因为firefox版本升级,在某个版本(可能是32左右)的某些改变,该扩展的重发请求功能坏掉了,查看该扩展的官方也有相应的bug报告

从这一页面里https://www.mozdev.org/bugs/show_bug.cgi?id=25831,有国外高手回复说的修正版,修正版在 http://rghost.net/58012556 可以直接下载,然后在通过firefox菜单-文件-打开,浏览到该xpi包安装

为防失效,转来一份 livehttpheaders,是zip压缩过的(wordpress限制文件格式),下载后解压缩后再按上法安装

firefox 45左右某版本下解决方案

[20160708]

firefox 某个版本强制要求扩展的签名机制,至少ESR 45起上面xpi文件已经不能安装了,提示说“似乎已损坏”。

经过探索,发现可以将上述xpi文件解压后的chrome/livehttpheaders.jar文件的替换firefox用户目录里相应的文件即可。不过,firefox重启后,签名验证会再次禁止扩展;换回去再改一次好了。虽然很麻烦,但勉强能用。

  • livehttpheaders.jar 文件可以直接从这里下载livehttpheaders__unpacked-file-livehttpheaders-jar,是zip压缩过的(wordpress限制文件格式),使用前先解压。
  • 我的firefox用户目录里相应位置在,具体请自行寻找一下  C:\Users\Administrator\AppData\Roaming\Mozilla\Firefox\Profiles\d1cain74.default\extensions\{8f8fe09b-0bd3-4470-bc1b-8cad42b8203a}\chrome

由此判断,firefox扩展的签名验证机制,只是在扩展安装及firefox启动时验证,firefox运行中是不检查的。

live http headers重发请求功能的示例

live_http_headers_replylive_http_headers_reply

坑啊!virtual box差分磁盘文件在修改虚拟机后会被清空!

被坑死了,下载一夜的文件,白下载了!

事情这样:
「背景」因为ssd空间较小,vbox里的win xp虚拟机,使用的动态差分硬盘:原始磁盘文件在sata盘上,差分文件放到ssd上,这样磁盘性能会比较好。虚拟硬盘设置的20G,比较小。
「发现」昨晚下载了几个大文件,在解压缩时,磁盘空间不够了,于是再分配一块新硬盘上去,机器重启后,发现系统竟然被还原了。查了磁盘文件,发现差分文件只有50M,这肯定不对。到处找,也没有。
「确认」为了验证一下,在v xp里做了一些文件修改,让磁盘差分文件大一点,然后把第二块盘从配置里移除,果然,

【161010补】之前看这篇草稿,想完成并发布之,但没动。一个主要原因是,仔细想想,vbox这样的设定,其实是合理的。怪自己当时的自作聪明。

本文是以前一次悲惨经历的记录。在草稿箱里放了1年多,最近整理博客看其更新时间为 2015年9月12日 @ 09:05,这么久都没有继续写,大概以后也不会续写,直接发出来算了(2016-10-10 16:46)。

filezilla server手工修改配置文件及重加载生效/命令行参考等

使用filezilla server自带的配置工具,修改用户(或用户组)目录权限时,浏览文件是很麻烦的事情,要一级一级展开,尤其是目录比较深的时候。这时,推荐手工修改配置文件 FileZilla Server.xml 。

以下示例假定filezilla server安装在 D:\Program Files\FileZilla Server

安装目录下文件 FileZilla Server.xml 即配置文件。该文件结构很清晰,而且有良好排版。每个用户(或组),下面都有 <Permissions> ... </Permissions> 节点,其中每个目录是一个 Permission节点,其中多个option,定义几种操作的权限。

下面是几种常用的权限示例,需要增减目录配置时,直接复制相应的 <Permission ...>.....</Permission> 节点 ,修改其中目录 Dir 即可

<label>readonly 只读权限</label>

                <Permission Dir="E:\web\tools">
                    <Option Name="FileRead">1</Option>
                    <Option Name="FileWrite">0</Option>
                    <Option Name="FileDelete">0</Option>
                    <Option Name="FileAppend">0</Option>
                    <Option Name="DirCreate">0</Option>
                    <Option Name="DirDelete">0</Option>
                    <Option Name="DirList">1</Option>
                    <Option Name="DirSubdirs">1</Option>
                    <Option Name="IsHome">0</Option>
                    <Option Name="AutoCreate">0</Option>
                </Permission>


<label>allaccess 所有权限,包括读写删除管理目录等</label>

                <Permission Dir="E:\web\tools">
                    <Option Name="FileRead">1</Option>
                    <Option Name="FileWrite">1</Option>
                    <Option Name="FileDelete">1</Option>
                    <Option Name="FileAppend">1</Option>
                    <Option Name="DirCreate">1</Option>
                    <Option Name="DirDelete">1</Option>
                    <Option Name="DirList">1</Option>
                    <Option Name="DirSubdirs">1</Option>
                    <Option Name="IsHome">0</Option>
                    <Option Name="AutoCreate">0</Option>
                </Permission>


<label>basic_write 常规的文件读写权限,不允许增删目录操作</label>

                <Permission Dir="E:\web\tools">
                    <Option Name="FileRead">1</Option>
                    <Option Name="FileWrite">1</Option>
                    <Option Name="FileDelete">1</Option>
                    <Option Name="FileAppend">1</Option>
                    <Option Name="DirCreate">1</Option>
                    <Option Name="DirDelete">0</Option>
                    <Option Name="DirList">1</Option>
                    <Option Name="DirSubdirs">1</Option>
                    <Option Name="IsHome">0</Option>
                    <Option Name="AutoCreate">0</Option>
                </Permission>


<label>no_access 无任何权限,包括读写文件,列出目录等</label>

                <Permission Dir="E:\web\tools">
                    <Option Name="FileRead">0</Option>
                    <Option Name="FileWrite">0</Option>
                    <Option Name="FileDelete">0</Option>
                    <Option Name="FileAppend">0</Option>
                    <Option Name="DirCreate">0</Option>
                    <Option Name="DirDelete">0</Option>
                    <Option Name="DirList">0</Option>
                    <Option Name="DirSubdirs">0</Option>
                    <Option Name="IsHome">0</Option>
                    <Option Name="AutoCreate">0</Option>
                </Permission>

即如上

,修改后,不需要重启,只需在命令行下重新加载权限即可,示例

D:\Program Files\FileZilla Server>"FileZilla Server.exe" /reload-config

"FileZilla Server.exe"  不像unix程序一样自带help,经查官方手册,转载如下

-------------- "FileZilla Server.exe" Command-line arguments  ------------------
Starting and stopping the service:

/start
/stop

Installing the service for manual startup:

/install

Installing the service for start at boot:

/install auto

Uninstalling service:

/uninstall

Reloading configuration at runtime:

/reload-config

--------------------------------

 

windows下filezilla server安装配置及安全加固

以  FileZilla_Server-0_9_41.exe 为例

1  安装
FileZilla_Server-0_9_41.exe

2  从开始菜单里停止Filezilla_server服务

3  到安装目录里改名备份(或直接删掉)文件 FileZilla server.exe
典型位置: "C:\Program Files (x86)\FileZilla Server" (64位机器上) 或 "C:\Program Files\FileZilla Server" (32位机器上)

4  从默认ansi编码的filezilla server补丁包里压缩出 FileZilla server.exe ,拷到如上安装目录里。

5  创建一个独立的windows用户、一个windows用户组,用于运行ftp服务,用户名为webftp
(默认情况下,windows服务以SYSTEM用户运行,几乎等同于管理员;这是重大安全隐藏,如果该服务有漏洞并被恶意利用,后果...)

6  到windows服务列表中,双击 "FileZilla Server FTP server",打开服务属性窗口 - 登录
“登录身份” - 选择 “此账户” - 浏览 - 选择到刚建立的独立用户webftp
回到“服务恢属性”窗口,输入账号密码,“应用”或“确定”

6  启动服务(从开始菜单或服务列表皆可),观察windows任务管理器中,进程"FileZilla server.exe" 的用户名是否是 webftp

7  修改将filezilla server安装目录权限:webftp用户有读取权限
只保留 SYSTEM, webftp, Administrators 三个用户的权限,其它删掉

修改安装目录中的 文件  "FileZilla Server.xml", "FileZilla Server Interface.xml" 权限,为webftp用户赋写入权限

8  windows默认对每个硬盘分区设置了较多权限,只保留administrator,system,users,其它删除(通常Users也可以删除)
(否则,权限极低的webftp用户将可以在相应目录的读取甚至写入的权限;或许是因为everyone用户的存在)

8  windows了防火墙,添加一条规则,按程序的规则添加规则(非按端口):allow_filezilla-server_in
新建入站规则- 规则类型:程序(P) - 此程序路径 - 浏览到 FileZilla server.exe - 允许连接

------------------------------------
* 关于ftp目录的权限设置
对于需要通过ftp管理(包括读取或删除写入等)的所有目录(文件)
检查是否有不该买有的权限,最好是严格按照“最低权限”原则进行设置。
对这些目录(文件),根据需要,赋给ftp用户权限,至少需要一个读取权限。
如果不需要通过ftp删除的文件(夹),可以不赋修改写入权限

删除windows上lpt1.asp伪装木马文件(SHR属性),及一次查杀web木马简记

维护的一台windows 2003服务器,跑iis6,其中一个站点需要同时支持asp与php,还得跟站点web用户赋写入权限(因为该站主要是一asp的CMS,文章内容页是生成静态html的)。正因如此,该站比较容易出问题,数次被挂马。

在与该CMS还有入侵者长期的拉锯战里,该站点做了很多针对性的措施,比如,

  • 删除iis里动态脚本映射,只保留.asp, .php, .shtml,其它的像.net的一大堆(,.cs什么什么的),全部删除
  • 改进cms程序的写入文件功能:禁止写asp, php文件,增强上传功能安全性,等
  • 非动态脚本目录(如文件上传目录等),通过iis设置无执行权限
  • 后来更严苛的设置,除了少数几个有必要的目录,其它目录下的.asp, .php全部重写到一个空文件上。通过rewrite实现

不过后来,还是出过问题。

如这一次,根据被挂马文件的写入时间,找之前一天内被修改过(包括写入)的.asp, .php文件,在查iis日志,里查找马儿文件被请求的记录项,找到马夫的ip,当然ip很可能是动态变化的,不过这次好像是全部从一个ip上还的,这就省功夫了。分析该ip的请求记录,专找对.asp, .php url的请求,尤其是 POST请求(因为webshell大马的处理很复杂,一般都是post传参数),仔细检查这些.asp, .php文件的修改时间,最近被修改过的,一定可疑。修改时间是很久以前,也不能吊心轻心,有可能是长期隐蔽马。

按上面的步骤,清理木马不是太难的事情。但就怕遗漏,一个小小马(通常是一句话或其变种),足以让这些工作白费。

不过这次发现了一个名为 lpt1.asp 的文件,而且是“系统 隐藏 只读”的属性SHR,删除时提示找不到文件,有点奇怪了,看文件名,有点奇怪;使用编辑器打开,也提示文件不存在。担心操作系统被植入了什么进程,这就麻烦了。google得知,lpt1这是dos保留字的文件名,要使用一个咒语般的路径地址,很蛋疼。。。

根据搜索结果,该文件位于 E:\www\site_root\images\lpt1.asp 相应的地址是 \\.\E:\www\site_root\images\lpt1.asp ,即

del \\.\E:\www\site_root\images\lpt1.asp

结果是不行,怀疑是SHR的关系,尝试一阵子,通过这样的形式:

attrib -S -R -H path_to_file.ext

清理掉这几个属性;似乎这几个属性要一次性去除,还不能一个一个的去除;好像不是dos的风格,竟然支持一次多个item的操作。。。。

然后可以删除了,当然,我在删除前做了个备份,毕竟又截获了一只马。

下面是一部分操作的记录,帖出来了

E:\www\site_root\images>del E:\www\site_root\images\lpt1.asp
文件名、目录名或卷标语法不正确。

E:\www\site_root\images>attrib \\.\E:\www\site_root\images\lpt1.asp
A  SHR     \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>del E:\www\site_root\images\lpt1*
找不到 E:\www\site_root\images\lpt1*

E:\www\site_root\images>del E:\www\site_root\images\lp*

E:\www\site_root\images>attrib \\.\E:\www\site_root\images\lpt1.asp
A  SHR     \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>attrib \\.\E:\www\site_root\images\lpt1.asp
A  SHR     \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>attrib -H \\.\E:\www\site_root\images\lpt1.asp
未重设系统文件 - \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>attrib -S -R -H \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>attrib -H \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>attrib \\.\E:\www\site_root\images\lpt1.asp
A          \\.\E:\www\site_root\images\lpt1.asp


E:\www\site_root\images>attrib \\.\E:\www\site_root\images\lpt1.asp
A          \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>copy \\.\E:\www\site_root\images\lpt1.asp f:\aa.txt
已复制         1 个文件。

E:\www\site_root\images>del \\.\E:\www\site_root\images\lpt1.asp

本文是以前写的一篇手记,处理后以为问题得解,但稍后两天发现仍被入侵,于是次本文状态改成草稿;被入侵的原因是其他地方仍然有木马,处理后本文丢在这里没有动。这么久都没有继续写,大概以后也不会续写,最近整理博客时就直接发出来算了(2016-10-10 16:20)

磁盘空间爆掉时nginx报错 An error occurred

nginx报错了,消息如下错误如下nginx_Error_disk_empty

An error occurred.

Sorry, the page you are looking for is currently unavailable.
Please try again later.

If you are the system administrator of this resource then you should check the error log for details.

Faithfully yours, nginx.

1分钟前还是好的,至少wordpress后台可以正常打开,突然就成这样子了。静态页面还正常,就ssh上,检查php-fpm进程是正常的,没有僵局。算了,杀死,连nginx一起杀死,虽然这是很不优雅的行为,所不齿的行为。然而结果是没用。随手查了下df -h ,分区满了,怪不得,查了下,删除几个备份文件,然后一切恢复正常了。空间不够,还是个问题,要进一步清理了。

Pages: 1 2 3 4 5 Next