WordPress架设多域名多站点教程

WordPress 3.0以上的版本支持直接开启多站点模式,这样一来,你可以在一个后台切换多个站点进行管理。多站点模式可以使用多个不同的域名绑定,避免了在同一个服务器安装多个WordPress的尴尬,管理多个网站非常方便,下面就介绍一下安装和启用多站点的操作方法。

开启网络配置

在网站根目录下的 wp-config.php 添加:

define('WP_ALLOW_MULTISITE', true);

  
配置多站点模式

  刷新网站后台,访问 工具 > 配置网络,根据自己的需要选择“子域名”或者“子目录”模式,然后点击“安装”,如果需要绑定域名,可以选择“子域名”模式。之后系统会生成两段代码,一段添加到网站根目录下的 wp-config.php 中,一段添加到网站根目录下的 .htaccess 文件中。

添加网站域名

  服务器Apache设置为泛域名解析,然后在 我的站点 – 管理网络 – 站点 里,添加新的站点,选一个子域名添加站点。

  添加好了以后,在子域名上点编辑,把里面的“站点地址(URL)”修改为指定的独立域名,然后将该独立域名DNS绑定过来,即可完成配置。

设置COOKIE

在网站根目录下的 wp-config.php 添加:

define( 'COOKIE_DOMAIN', '' );

  这步操作很重要,如果不设置的话,之后登录网站后台会提示“错误:Cookies被阻止或者您的浏览器不支持。要使用WordPress,您必须启用Cookies。”

  之后,用户就可以用一套WordPress程序来管理多个不同的站点,可以同步调整主题和插件,这些站点可以是完全不同的域名,管理起来非常方便。

Tomcat是怎样处理搜索引擎爬虫请求的?

每个置身于互联网中的站点,都需要搜索引擎的收录,以及在适时在结果中的展现,从而将信息提供给用户、读者。而搜索引擎如何才能收录我们的站点呢?

这就涉及到一个「搜索引擎的爬虫」爬取站点内容的过程。只有被搜索引擎爬过并收录的内容才有机会在特定query命中之后在结果中展现。

这些搜索引擎内容的工具,又被称为爬虫、Sprider,Web crawler 等等。我们一方面欢迎其访问站点以便收录内容,一方面又因其对于正常服务的影响头疼。毕竟 Spider 也是要占用服务器资源的, Spider 太多太频繁的资源占用,正常用户请求处理就会受到影响。所以一些站点干脆直接为搜索引擎提供了单独的服务供其访问,其他正常的用户请求走另外的服务器。

说到这里需要提一下,对于是否是 Spider 的请求识别,是通过HTTP 请求头中的User-Agent 字段来判断的,每个搜索引擎有自己的独立标识。而且通过这些内容,管理员也可以在访问日志中了解搜索引擎爬过哪些内容。

此外,在对搜索引擎的「爬取声明文件」robots.txt中,也会有类似的User-agent 描述。比如下面是taobao 的robots.txt描述

User-agent:  Baiduspider 
Allow:  /article 
Allow:  /oshtml 
Disallow:  /product/ 
Disallow:  / 

User-Agent:  Googlebot 
Allow:  /article 
Allow:  /oshtml 
Allow:  /product 
Allow:  /spu 
Allow:  /dianpu 
Allow:  /oversea 
Allow:  /list 
Disallow:  / 

User-agent:  Bingbot 
Allow:  /article 
Allow:  /oshtml 
Allow:  /product 
Allow:  /spu 
Allow:  /dianpu 
Allow:  /oversea 
Allow:  /list 
Disallow:  / 

User-Agent:  360Spider 
Allow:  /article 
Allow:  /oshtml 
Disallow:  / 

User-Agent:  Yisouspider 
Allow:  /article 
Allow:  /oshtml 
Disallow:  / 

User-Agent:  Sogouspider 
Allow:  /article 
Allow:  /oshtml 
Allow:  /product 
Disallow:  / 

User-Agent:  Yahoo!  Slurp 
Allow:  /product 
Allow:  /spu 
Allow:  /dianpu 
Allow:  /oversea 
Allow:  /list 
Disallow:  / 

我们再来看 Tomcat对于搜索引擎的请求做了什么特殊处理呢?
对于请求涉及到 Session,我们知道通过 Session,我们在服务端得以识别一个具体的用户。那 Spider 的大量请求到达后,如果访问频繁同时请求量大时,就需要创建巨大量的 Session,需要占用和消耗很多内存,这无形中占用了正常用户处理的资源。

为此, Tomcat 提供了一个 「Valve」,用于对 Spider 的请求做一些处理。

首先识别 Spider 请求,对于 Spider 请求,使其使用相同的 SessionId继续后面的请求流程,从而避免创建大量的 Session 数据。
这里需要注意,即使Spider显式的传了一个 sessionId过来,也会弃用,而是根据client Ip 来进行判断,即对于 相同的 Spider 只提供一个Session。

我们来看代码:

// If the incoming request has a valid session ID, no action is required 
if (request.getSession(false) == null) { 

    // Is this a crawler - check the UA headers 
    Enumeration<String> uaHeaders = request.getHeaders("user-agent"); 
    String uaHeader = null; 
    if (uaHeaders.hasMoreElements()) { 
        uaHeader = uaHeaders.nextElement(); 
    } 

    // If more than one UA header - assume not a bot 
    if (uaHeader != null && !uaHeaders.hasMoreElements()) { 
        if (uaPattern.matcher(uaHeader).matches()) { 
            isBot = true; 
            if (log.isDebugEnabled()) { 
                log.debug(request.hashCode() + 
                        ": Bot found. UserAgent=" + uaHeader); 
            } 
        } 
    } 

    // If this is a bot, is the session ID known? 
    if (isBot) { 
        clientIp = request.getRemoteAddr(); 
        sessionId = clientIpSessionId.get(clientIp); 
        if (sessionId != null) { 
            request.setRequestedSessionId(sessionId); // 重用session 
        } 
    } 
} 

getNext().invoke(request, response); 

if (isBot) { 
    if (sessionId == null) { 
        // Has bot just created a session, if so make a note of it 
        HttpSession s = request.getSession(false); 
        if (s != null) { 
            clientIpSessionId.put(clientIp, s.getId()); //针对Spider生成session 
            sessionIdClientIp.put(s.getId(), clientIp); 
            // #valueUnbound() will be called on session expiration 
            s.setAttribute(this.getClass().getName(), this); 
            s.setMaxInactiveInterval(sessionInactiveInterval); 

            if (log.isDebugEnabled()) { 
                log.debug(request.hashCode() + 
                        ": New bot session. SessionID=" + s.getId()); 
            } 
        } 
    } else { 
        if (log.isDebugEnabled()) { 
            log.debug(request.hashCode() + 
                    ": Bot session accessed. SessionID=" + sessionId); 
        } 
    } 
} 

判断Spider 是通过正则

private String crawlerUserAgents = 
    ".*[bB]ot.*|.*Yahoo! Slurp.*|.*Feedfetcher-Google.*"; 
// 初始化Valve的时候进行compile 
uaPattern = Pattern.compile(crawlerUserAgents); 

这样当 Spider 到达的时候就能通过 User-agent识别出来并进行特别处理从而减小受其影响。

这个 Valve的名字是:「CrawlerSessionManagerValve」,好名字一眼就能看出来作用。

其他还有问题么?我们看看,通过ClientIp来判断进行Session共用。
最近 Tomcat 做了个bug fix,原因是这种通过ClientIp的判断方式,当 Valve 配置在Engine下层,给多个Host 共用时,只能有一个Host生效。 fix之后,对于请求除ClientIp外,还有Host和 Context的限制,这些元素共同组成了 client标识,就能更大程度上共用Session。
修改内容如下:

未分类

总结下, 该Valve 通过标识识别出 Spider 请求后,给其分配一个固定的Session,从而避免大量的Session创建导致我资源占用。
默认该Valve未开启,需要在 server.xml中 增加配置开启。另外我们看上面提供的 正则 pattern,和taobao 的robots.txt对比下,你会出现并没有包含国内的这些搜索引擎的处理,这个时候怎么办呢?
在配置的时候传一下进来就OK啦,这是个public 的属性

public void setCrawlerUserAgents(String crawlerUserAgents) { 
    this.crawlerUserAgents = crawlerUserAgents; 
    if (crawlerUserAgents == null || crawlerUserAgents.length() == 0) { 
        uaPattern = null; 
    } else { 
        uaPattern = Pattern.compile(crawlerUserAgents); 
    } 
}

自用ssh命令总结

最近工作有涉及ssh相关,学习中会不断更新修改

通过cgywin,xshell,linux,堡垒机等连接ssh ,具体方法之后会补充 

  1. SSH可以连接到远程主机; 

  2. SCP后面是 /开头是本地地址, xx@xxxx: 用户名@ip地址+ / remote地址 ; 

  3. ssh -i +(直接拖动来的证书文件)+ ip ( 物理ip还是虚拟ip?)
    例如 ssh -i xxx.xxx.xxx.xxx:./ ; 

  4. 本地拷贝到远程设备:scp -i +(直接拖动来的证书)+ (带地址的本地文件,直接拖动来)
    +要移动的ip:路径(绝对路径或者相对路径)

    例如 scp -i xx/xx/id_rsa.rsa ../xx/test.lua xxx.xxx.xxx.xxx:./:./ ; 

  5. 远程主机下载到本机,将远程ip的文件和本机文件调换位置即可; 

  6. ssh连接远程主机后,可以用logcat监控当前安卓设备的操作,例如点击进入某个app,通过logcat看包名; 

  7. ssh后, getevent -l 可以查看当前鼠标在安卓设备上点击的位置(注意坐标点,和16进制需要转换);

  8. 可以在安卓手机的设置里面查看ip地址 

  9. ls:当前路径下的文件, pwd:当前目录所在路径, cat:查看文件, cgywin修改文件需要下载vim模块,
    ifconfig: 注意是if而不是ip,查看ip等信息 ,有时候scp和安装需要调整权限

  10. 可以通过ssh查看当前设备的ip等信息: 例如 /data/lxc/bin/lxc-info -n 0 

  11. 有时候ssh连接需要将证书放到cgywin的bin目录下跑一次

Mac使用ssh公钥登录Linux

ssh登录Linux通常有两种方法:用户名密码登录、用户名公钥登录;使用用户名密码登录每次都要输入密码,相当麻烦,而使用用户名公钥登录则可以避免这个问题。

创建公钥私钥文件
打开本地终端,执行 ssh-keygen 命令创建密钥对:

ssh-keygen -t rsa -C  'your [email protected]'

-t 指定密钥类型,默认即 rsa ,可以省略
-C 设置注释文字,比如你的邮箱,可以省略

生成过程中会提示输入密码两次,如果不想在使用公钥的时候输入密码,可以回车跳过;
密钥默认保存位置在 ~/.ssh 目录下,打开后会看到私钥文件 id_rsa 和公钥文件 id_rsa.pub;

未分类

复制公钥至服务器
使用 scp 命令将本地的公钥文件 id_rsa.pub 复制到需要连接的Linux服务器:

scp ~/.ssh/id_rsa.pub <用户名>@<ip地址>:/home/id_rsa.pub

如果修改了ssh默认连接端口的话,需要加上端口信息:

scp -P <端口号> ~/.ssh/id_rsa.pub <用户名>@<ip地址>:/home/id_rsa.pub

把公钥追加到服务器ssh认证文件中:

cat /home/id_rsa.pub >> ~/.ssh/authorized_keys

未分类

这时候在本地终端中使用用户名和ip登录就不需要密码了:

ssh <用户名>@<ip>

未分类

如果修改了ssh默认连接端口的话,需要加上端口信息:

ssh -p <端口号> <用户名>@<ip地址>

未分类

配置快捷登录
即使不用输入密码,这样每次登录还要输入用户名ip端口信息还是有点麻烦,我们可以配置ssh快捷登录更方便的登录Linux;
在本地 ~/.ssh/config 配置文件中添加ssh服务器信息,格式:

Host            alias            #自定义别名
HostName        hostname         #替换为你的ssh服务器ip或domain
Port            port             #ssh服务器端口,默认为22
User            user             #ssh服务器用户名
IdentityFile    ~/.ssh/id_rsa    #第一个步骤生成的公钥文件对应的私钥文件

未分类

这时候就可以使用配置文件中自定义的别名来登录了:

未分类

rsync+inotify实现实时同步案例

公司网站因负载过高不得不搞个负载均衡,那么问题来了,每次更新网站,负载均衡下的服务器全部需要更新,当数据量过大的时候会很麻烦,并切效率低下,当时考虑到用rsync去实时同步,写个计划任务,但更新数据很频繁,并且rsync不能实时的去监测、同步数据,虽然它可以通过linux守护进程的方式进行触发同步,但是两次触发动作一定会有时间差,这样就导致了服务端和客户端数据可能出现不一致,无法在应用故障时完全的恢复数据。基于以上原因,rsync+inotify出现了!

inotify介绍

inotify是一种强大的、细粒度的、异步的文件系统事件控制机制。linux内核从2.6.13起,加入了inotify支持,通过inotify可以监控文件系统中添加、删除、修改、移动等各种事件,利用这个内核接口,第三方软件就可以监控文件系统下文件的各种变化情况,而inotify-tools正是实施监控的软件。

rsync+inotify同步逻辑图
未分类

环境部署

主机名                主机IP地址            系统版本                系统内核版本
inotify-master    192.168.1.1    CentOS release 6.4 (Final)    2.6.32-358.el6.x86_64
inotify-slave    192.168.1.2    CentOS release 6.4 (Final)    2.6.32-358.el6.x86_64

inotify-slave部署

部署rsync服务,rsync daemon工作模式。

检查是否安装rsync

[root@inotify-slave ~]# rpm -aq rsync
rsync-3.0.6-9.el6.x86_64

新建rsync用户及模块目录并更改其用户组

[root@inotify-slave mail]# useradd rsync -s /sbin/nologin  -M #添加rsync用户
[root@inotify-slave mail]# grep rsync /etc/passwd
rsync:x:2004:2004::/home/rsync:/sbin/nologin
[root@inotify-slave mail]# mkdir /backup   #创建rsync daemon工作模式的模块目录
[root@inotify-slave mail]# ll -d /backup/
drwxr-xr-x. 2 root root 4096 4月  22 14:13 /backup/
[root@inotify-slave mail]# chown rsync.rsync /backup/   #更改模块目录的用户组
[root@inotify-slave mail]# ll -d /backup/
drwxr-xr-x. 2 rsync rsync 4096 4月  22 14:13 /backup/

编写rsync daemon配置文件/etc/rsyncd.conf

[root@inotify-slave /]# cat /etc/rsyncd.conf
##rsyncd.conf start##
#工作中指定用户(需要指定用户)
uid = rsync
gid = rsync
#相当于黑洞.出错定位
use chroot = no
#有多少个客户端同时传文件
max connections = 200
#超时时间
timeout = 300
#进程号文件
pid file = /var/run/rsyncd.pid
#日志文件
lock file = /var/run/rsync.lock
#日志文件
log file = /var/log/rsyncd.log
#模块开始
#这个模块对应的是推送目录
#模块名称随便起
[backup]
#需要同步的目录
path = /backup/
#表示出现错误忽略错误
ignore errors
#表示网络权限可写(本地控制真正可写)
read only = false
#这里设置IP或让不让同步
list = false
#指定允许的网段
hosts allow = 192.168.1.0/24
#拒绝链接的地址,一下表示没有拒绝的链接。
hosts deny = 0.0.0.0/32
#不要动的东西(默认情况)
#虚拟用户
auth users = rsync_backup
#虚拟用户的密码文件
secrets file = /etc/rsync.password
#配置文件的结尾
#rsync_config_______________end

配置虚拟用户的密码文件

[root@inotify-slave /]# echo "rsync_backup:leesir" >/etc/rsync.password
[root@inotify-slave /]# cat /etc/rsync.password
rsync_backup:leesir   #注:rsync_backup为虚拟用户,leesir为这个虚拟用户的密码
[root@inotify-slave /]# chmod 600 /etc/rsync.password #为密码文件提权,增加安全性
[root@inotify-slave /]# ll /etc/rsync.password
-rw-------. 1 root root 20 4月  22 14:20 /etc/rsync.password

启动rsync 服务

[root@inotify-slave /]# rsync --daemon   #启动rsync服务
[root@inotify-slave /]# ps -ef |grep rsync
root     14871     1  0 14:24 ?        00:00:00 rsync --daemon
root     14873 14788  0 14:24 pts/0    00:00:00 grep rsync
[root@inotify-slave /]# netstat -lnutp |grep rsync
tcp        0      0 0.0.0.0:873                 0.0.0.0:*                   LISTEN      14871/rsync
tcp        0      0 :::873                      :::*                        LISTEN          14871/rsync

通过inotify-master测试推送

inotify-master配置密码文件,测试推送
[root@inotify-master ~]# echo "leesir" >/etc/rsync.password
[root@inotify-master ~]# cat /etc/rsync.password
leesir   #注意:这里只要写密码即可,切记。
[root@inotify-master ~]# chmod 600 /etc/rsync.password
[root@inotify-master ~]# ll /etc/rsync.password
-rw------- 1 root root 7 4月  22 14:32 /etc/rsync.password
[root@inotify-master ~]# echo "hello leesir">test.txt
[root@inotify-master ~]# cat test.txt
hello leesir
[root@inotify-master ~]# rsync -avz test.txt [email protected]::backup --password-file=/etc/rsync.password
sending incremental file list
test.txt
sent 82 bytes  received 27 bytes  72.67 bytes/sec
total size is 13  speedup is 0.12
inotify-slave检查:
[root@inotify-slave /]# ll /backup/
总用量 4
-rw-r--r--. 1 rsync rsync 13 4月  22 14:34 test.txt
[root@inotify-slave /]# cat /backup/test.txt
hello leesir

inotify-master部署

注: inotify是rsync客户端安装和执行的 企业场景压力测试200-300个同步限制,受网卡,磁盘,带宽等的制约。

查看当前系统是否支持inotify

[root@inotify-master ~]# ll /proc/sys/fs/inotify/
总用量 0
-rw-r--r-- 1 root root 0 4月  22 14:56 max_queued_events
-rw-r--r-- 1 root root 0 4月  22 14:56 max_user_instances
-rw-r--r-- 1 root root 0 4月  22 14:56 max_user_watches
#显示这三个文件则证明支持。

拓展:

/proc/sys/fs/inotify/max_queued_evnets      
表示调用inotify_init时分配给inotify instance中可排队的event的数目的最大值,超出这个值的事件被丢弃,但会触发IN_Q_OVERFLOW事件。
/proc/sys/fs/inotify/max_user_instances 
表示每一个real user ID可创建的inotify instatnces的数量上限。
/proc/sys/fs/inotify/max_user_watches 
表示每个inotify instatnces可监控的最大目录数量。如果监控的文件数目巨大,需要根据情况,适当增加此值的大小。
例如: echo 30000000 > /proc/sys/fs/inotify/max_user_watches

下载inotify源码包并编译安装

root@inotify-master tools]# wget http://github.com/downloads/rvoicilas/inotify-tools/inotify-tools-3.14.tar.gz  #下载inotify源码包
..................................
root@inotify-master tools]# ll inotify-tools-3.14.tar.gz
-rw-r--r-- 1 root root 358772 3月  14 2010 inotify-tools-3.14.tar.gz
[root@inotify-master tools]# tar zxf inotify-tools-3.14.tar.gz
[root@inotify-master tools]# cd inotify-tools-3.14
[root@inotify-master inotify-tools-3.14]# ./configure --prefix=/usr/local/inotify-3.14 #配置inotify,并指定安装路径为/usr/local/inotify-3.14
................................
[root@inotify-master inotify-tools-3.14]# make && make install
................................

inotify之inotifywait命令常用参数详解

[root@inotify-master inotify-tools-3.14]# cd /usr/local/inotify-3.14/
[root@inotify-master inotify-3.14]# ./bin/inotifywait --help
-r|--recursive   Watch directories recursively. #递归查询目录
-q|--quiet      Print less (only print events). #打印监控事件的信息
-m|--monitor   Keep listening for events forever.  Without this option, inotifywait will exit after one  event is received.        #始终保持事件监听状态
--excludei <pattern>  Like --exclude but case insensitive.    #排除文件或目录时,不区分大小写。
--timefmt <fmt> strftime-compatible format string for use with %T in --format string. #指定时间输出的格式
--format <fmt>  Print using a specified printf-like format string; read the man page for more details.
#打印使用指定的输出类似格式字符串
-e|--event <event1> [ -e|--event <event2> ... ] Listen for specific event(s).  If omitted, all events are  listened for.   #通过此参数可以指定需要监控的事件,如下所示:
Events:
access           file or directory contents were read       #文件或目录被读取。
modify           file or directory contents were written    #文件或目录内容被修改。
attrib            file or directory attributes changed      #文件或目录属性被改变。
close            file or directory closed, regardless of read/write mode    #文件或目录封闭,无论读/写模式。
open            file or directory opened                    #文件或目录被打开。
moved_to        file or directory moved to watched directory    #文件或目录被移动至另外一个目录。
move            file or directory moved to or from watched directory    #文件或目录被移动另一个目录或从另一个目录移动至当前目录。
create           file or directory created within watched directory     #文件或目录被创建在当前目录
delete           file or directory deleted within watched directory     #文件或目录被删除
unmount         file system containing file or directory unmounted  #文件系统被卸载

编写监控脚本并加载到后台执行

[root@inotify-master scripts]# cat inotify.sh
#!/bin/bash
#para
host01=192.168.1.160  #inotify-slave的ip地址
src=/backup/        #本地监控的目录
dst=backup         #inotify-slave的rsync服务的模块名
user=rsync_backup      #inotify-slave的rsync服务的虚拟用户
rsync_passfile=/etc/rsync.password   #本地调用rsync服务的密码文件
inotify_home=/usr/local/inotify-3.14    #inotify的安装目录
#judge
if [ ! -e "$src" ] 
|| [ ! -e "${rsync_passfile}" ] 
|| [ ! -e "${inotify_home}/bin/inotifywait" ] 
|| [ ! -e "/usr/bin/rsync" ];
then
echo "Check File and Folder"
exit 9
fi
${inotify_home}/bin/inotifywait -mrq --timefmt '%d/%m/%y %H:%M' --format '%T %w%f' -e close_write,delete,create,attrib $src 
| while read file
do
#  rsync -avzP --delete --timeout=100 --password-file=${rsync_passfile} $src $user@$host01::$dst >/dev/null 2>&1
cd $src && rsync -aruz -R --delete ./  --timeout=100 $user@$host01::$dst --password-file=${rsync_passfile} >/dev/null 2>&1
done
exit 0
[root@inotify-master scripts]# sh inotify.sh &  #将脚本加入后台执行
[1] 13438
[root@inotify-master scripts]#

实时同步测试

inotify-master操作:

[root@inotify-master scripts]# cd /backup/
[root@inotify-master backup]# ll
总用量 0
[root@inotify-master backup]# for a in `seq 200`;do touch $a;done  #创建200个文件
[root@inotify-master backup]# ll  --time-style=full-iso
总用量 0
-rw-r--r-- 1 root root 0 2014-04-22 15:34:08.141497569 +0800 1
-rw-r--r-- 1 root root 0 2014-04-22 15:34:08.172497529 +0800 10
-rw-r--r-- 1 root root 0 2014-04-22 15:34:08.235497529 +0800 100
-rw-r--r-- 1 root root 0 2014-04-22 15:34:08.236497529 +0800 101
-rw-r--r-- 1 root root 0 2014-04-22 15:34:08.237497529 +0800 102
...................................

inotify-slave检查

[root@inotify-slave backup]# ll  --time-style=full-iso
总用量 0
-rw-r--r--. 1 rsync rsync 0 2014-04-22 15:34:08.393823754 +0800 1
-rw-r--r--. 1 rsync rsync 0 2014-04-22 15:34:08.393823754 +0800 10
-rw-r--r--. 1 rsync rsync 0 2014-04-22 15:34:08.393823754 +0800 100
-rw-r--r--. 1 rsync rsync 0 2014-04-22 15:34:08.393823754 +0800 101
-rw-r--r--. 1 rsync rsync 0 2014-04-22 15:34:08.393823754 +0800 102
..........................

如何为多个PHP-FPM容器构建单一的Nginx Docker镜像

在使用 Docker 容器来开发 PHP 微服务套件的过程中,作者遇到了容器数量过多的问题。

最近,我一直在使用 Docker 容器来开发 PHP 微服务套件。一个问题是 PHP 应用已经搭建,可以与 PHP-FPM 还有 Nginx(取代了简单的 Apche/PHP 环境)一起工作,因此每个 PHP 微服务需要两个容器(以及两个 Docker 镜像):一个 PHP-FPM 容器和一个 Nginx 容器。
这个应用运行了 6 个以上的服务,做个乘法就知道,在开发和生产之间会有约 30 个容器。于是我决定构建一个单独的 Nginx Docker 镜像,它可以使用 PHP-FPM 的主机名作为环境变量并运行单独的配置文件,而不用为每个容器构建单独的 Nginx 镜像。

未分类

在本文中,我介绍了自己从上图中的方法 1 到方法 2 的转换,最后采用的方案中采用了一种新的定制 Docker 镜像。该镜像的代码是开源的,如果读者碰到类似问题,可以提供给大家参考。

为什么用 Nginx?

Nginx 和 PHP-FPM 配合使用能使 PHP 应用的性能更好,但不好的地方在于,和 PHP Apache 镜像不同,PHP-FPM Docker 镜像默认不是和和 Nginx 绑定在一起的。如果需要通过 Nginx 容器和 PHP-FPM 连接,需要在 Nginx 配置里为该后端增加 DNS 记录。比如,如果名为 php-fpm-api 的 PHP-FPM 容器正在运行,Nginx 配置文件应该包含下面部分:

location ~ .php$ {
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        # This line passes requests through to the PHP-FPM container
        fastcgi_pass php-fpm-api:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

如果只服务于单独的 Nginx 容器,Nginx 配置中容器名字写死还可以接受,但如上所述,需要允许多个 Nginx 容器,每个对应于一个 PHP 服务。创建一个新的 Nginx 镜像(以后需要进行维护和升级)会有些痛苦,即使管理一批不同的数据卷,仅仅改变变量名看起来也有很多工作。

第一种方案: 使用 Docker 文档中的方法

最初,我认为这会很简单。Docker 文档中有少许的几个章节讨论如何使用 envsubst 来完成该工作,但不幸的是,在我的 Nginx 配置文件中,这种方法不奏效。

vhosts.conf

server {
    listen 80;
    index index.php index.html;
    root /var/www/public;
    client_max_body_size 32M;
    location / {
        try_files $uri /index.php?$args;
    }
    location ~ .php$ {
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass ${NGINX_HOST}:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

该vhosts.conf文件使用了 Nginx 内置变量,因此当依照文档运行 Docker 命令 (/bin/bash -c “envsubst < /etc/nginx/conf.d/mysite.template > /etc/nginx/conf.d/default.conf && nginx -g ‘daemon off;’”) 时,得到错误提示$uri和$fastcgi_script_name没有定义。这些变量通常通过 Nginx 传入,因此不能简单的识别出他们是什么并传给自身,而且这样会影响容器的动态配置。

使用另一个 Docker 镜像,差点成功

接下来,我开始研究不同的 Nginx 镜像。找到的有两个,但它们都在随后的几年中都没有任何更新。我开始使用 martin/nginx,试图找到可以工作的原型。

Martin 的镜像和其它镜像有点不一样,因为它要求特定的文件夹结构。在 root 下增加Dockerfile:

FROM martin/nginx

接下来,我添加了一个app/空目录和conf/目录,conf/目录下只有一个文件
vhosts.conf:

server {
    listen 80;
    index index.php index.html;
    root /var/www/public;
    client_max_body_size 32M;
    location / {
        try_files $uri /index.php?$args;
    }
    location ~ .php$ {
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass $ENV{"NGINX_HOST"}:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

这个文件和之前的配置文件几乎一样,除了有一行的改动:
fastcgi_pass $ENV{“NGINX_HOST”}:9000;。现在想要启动带命名为 php-fpm-api 的 PHP 容器的 Nginx 容器,就可以构建一个新的镜像,让它在以下环境变量下运行:

docker build -t shiphp/nginx-env:test .
docker run -it --rm -e NGINX_HOST=php-fpm-api shiphp/nginx-env:test

它可以正常工作了。但是,这种方法有两个困扰的地方:
正在使用的基础镜像已经有两年了。这会引入安全和性能风险。
有个空的/app目录看起来并不必需,因为文件会被存储在一个不同的目录中。

最终解决方案

我认为作为定制解决方案,从 Martin 镜像开始比较好,因此我给项目建了分叉,创建了新的 Nginx 基础镜像并修复了上述两个问题。现在,如果要在 Nginx 容器中允许动态命名的后端,可以参照:

# 从 Docker Hub 得到最新版本
docker pull shiphp/nginx-env:latest
# 运行名为"php-fpm-api"的 PHP 容器 
docker run --name php-fpm-api -v $(pwd):/var/www php:fpm
# 允许链接到 PHP-FPM 容器的 NGinx 容器
docker run --link php-fpm-api -e NGINX_HOST=php-fpm-api shiphp/nginx-env

如果想增加自己的文件或 Nginx 配置文件,来定制镜像,用Dockerfile来扩展它就可以:

FROM shiphp/nginx-env
ONBUILD ADD <PATH_TO_YOUR_CONFIGS> /etc/nginx/conf.d/
...

现在所有的 PHP-FPM 容器都能使用单个Docker镜像中自己的实例,这样在升级 Nginx,改变权限或做某些调整时,就变得非常轻松了。

所有的代码都在 Github 上,如果你看到任何问题或有改进建议,可以直接创建 issue。

GitHub 项目链接:https://github.com/shiphp/nginx-env

nginx 和 frp共用80端口

之前用frp做内网穿透,把内网的服务器开放到外网。

如果是http服务的话,80端口的做法是使用二级域名xxx做个A记录指一台没有nginx 之类的服务器IP,然后用浏览器打开xxx.example.com就打开了。其他端口是在frpc.ini里指定的,就加个端口号如xxx.example.com:1234就打开了,这种情况用于外网服务器已经有nginx在运行占用了80端口, 这时如果不想用端口号来打开,就要做三级域名解析,同时nginx做反向代理,把这个1234端口代理到80.

其实只要给 nginx 增加一个简单的配置,就可以将某个域名的流量转发给 frp 了,还可以通过泛解析来映射不同的网站。

配置 nginx:

server {
    listen 80;
    server_name *.frp.example.com;
    location / {
        proxy_pass http://127.0.0.1:8081;
        proxy_set_header    Host            $host:80;
        proxy_set_header    X-Real-IP       $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_hide_header   X-Powered-By;
    }
}

上面这段写入/etc/nginx/sites-avaliable/default的最后面,监听*.frp.example.com, 并转发给127.0.0.8081, 接下来只要将frp默认监听 80 端口改成 8081 端口就好了.

配置 frp 服务端:

[common]
bind_port = 8787
vhost_http_port = 8081
token = passwd
max_pool_count = 100
subdomain_host = frp.example.com

[xxx]
type = http
subdomain = xxx

重点在于将 vhost_http_port 设为 8081, 还可以在common下加上dashboard相关的端口,用户,密码等信息。

配置 frp 客户端:

[common]
server_addr = exampel.com 
server_port = 8787 
token = passwd
login_fail_exit = false 

[xxx]
type = http
local_port = 80
subdomain = xxx

域名设置:

1, 增加二级域名frp的A解析,到外网服务器IP.

  1. 增加三级域名泛解析*.frp的CNAME解析,到frp.example.com.

这时要做完这2个域名解析就可以用xxx.frp.example.com访问了。

参考:http://www.miss.cat/frp-use-80-port-with-nginx/

https://blog.csdn.net/qq_36560161/article/details/79646523

如果是ssh,frpc如下面配置的话,还是一样的,跟http上面讲的东西没有关系:

[common]
server_addr = example.com 
server_port = 8787 
token = passwd
login_fail_exit = false 

[ssh-xxx]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 5000

还是这样登录:

ssh [email protected] -p5000

WordPress禁用自动保存草稿去除文章修订功能

下面的方法需要修改源文件所以在打开每一个文件之前,记得一定要先做好备份!

禁用文章修订历史版本

1.打开 wp-config.php 文件
2.在 $table_prefix = ’wp_’; 前面添加下面的两行代码:

define('WP_POST_REVISIONS', false);//禁用历史修订版本
define('AUTOSAVE_INTERVAL', false);//自动保存时间设置为一天

如下:

未分类

禁用自动保存功能

1.打开 wp-admin/post.php 文件,搜索 if ( ’attachment’ !== $post_type ) ,找到以下代码 150-151行

if ( 'attachment' !== $post_type )
wp_enqueue_script('autosave');

将这两行用注释符号//注释即可!如下:

未分类

2.打开 wp-admin/post-new.php 文件,搜索 wp_enqueue_script( ’autosave’ ); (69行),在代码前面加//将其注释或删除

未分类

禁用自动草稿功能

打开 wp-adminincludespost.php 文件,搜索 if ( $create_in_db ) { 找到以下代码 597行

$post_id = wp_insert_post( array( 'post_title' => __( 'Auto Draft' ), 'post_type' => 
$post_type, 'post_status' => 'auto-draft' ) ); $post = get_post( $post_id );

修改为:

global $current_user,$wpdb; $post = $wpdb->get_row( "SELECT * FROM $wpdb->posts WHERE post_status = 'auto-draft' AND post_type = '$post_type' AND post_author = $current_user->ID ORDER BY ID ASC LIMIT 1" ); if (!($post) ) { $post_id = wp_insert_post( array( 'post_title' => __( 'Auto Draft' ), 'post_type' => $post_type, 'post_status' => 'auto-draft' ) ); $post = get_post( $post_id ); }

如下:

未分类

WordPress内核中一个任意文件删除漏洞,可导致攻击者执行任意代码

导语:WordPress是网络上最受欢迎的CMS。在这篇文章中,我们将讲述在WordPress内核中引入一个经认证的任意文件删除漏洞,这个漏洞可能会导致攻击者执行任意代码。

未分类

简介

WordPress是目前网络上最受欢迎的CMS。根据w3tech的资料显示,约有30%的网站都在使用它1。这种广泛的采用,也使其成为了网络犯罪分子非常感兴趣的一个目标。在这篇文章中,我们将讲述在WordPress内核中引入一个经认证的任意文件删除漏洞,这个漏洞可能会导致攻击者执行任意代码。在7个月前,我们向WordPress安全团队报告了这个漏洞,但至今依然没有得到修复。由于经过了这么长时间,WordPress官方都没有发布任何补丁或具体修复计划,所以我们决定公开这个事件。

受影响的版本

截止到本篇文章发送时,还没有补丁可防止此漏洞的使用。任何WordPress版本(包括当前的4.9.6版本),都容易受到该漏洞的影响。

如果要利用该漏洞,攻击者需要事先获得编辑和删除媒体文件的权限。因此,该漏洞可以通过对与作者权限相同的用户来提升权限,或者通过其他漏洞的错误配置来利用。

攻击带来的影响

利用此漏洞,使攻击者能够删除WordPress安装的任何文件(+ PHP服务器上的任何其他文件,PHP进程用户具有适当的删除权限)。除了删除整个WordPress安装文件对系统的影响(如果没有当前备份可用,会导致灾难性后果),攻击者可以利用任意文件删除功能绕过一些安全措施,并在Web服务器上执行任意代码。更确切地说,可以删除以下文件:

  • .htaccess:一般来说,删除此文件不会有不安全的影响。但是,在某些情况下,.htaccess文件包含与安全相关的约束(例如,对某些文件夹的访问限制)。因此,删除此文件将会禁用这些安全限制。

  • index.php文件:通常情况下,将空的index.php文件放置到目录中,以防止Web服务器无法执行的情况下的目录列表。如果删除这些文件则将为攻击者提供一份列表,列出受此措施保护的目录中的所有文件。

  • wp-config.php:删除这个WordPress安装文件,会在下次访问该网站时触发WordPress安装过程。这是因为wp-config.php包含数据库凭证,如果没有它,WordPress的将认为它尚未安装。攻击者可以删除该文件,使用管理员帐户选择的凭据进行安装过程,最后在服务器上执行任意代码。

如需观看视频,请点击此处查看原文https://blog.ripstech.com/2018/wordpress-file-delete-to-code-execution/

技术细节

当用户输入传递文件删除功能时,会发生任意文件删除漏洞。在PHP中,当unlink()调用该函数,并且用户输入可能会影响部分或整个参数$filename(表示要删除的文件的路径)时,会发生这种情况,而WordPress不会进行适当的处理。

在该wp-includes/post.php文件中找到了在WordPress Core中使这个漏洞成为可能的代码部分:

未分类

WordPress内核中一个任意文件删除漏洞,可导致攻击者执行任意代码
在wp_delete_attachement()上面显示的功能中,$meta[‘thumb’]呼叫中使用的内容unlink()未经过任何处理。这段代码的目的是在删除图像的同时删除图像的缩略图。在WordPress中通过媒体管理器上传的图像被表示为附属类型的帖子。该值$meta[‘thumb’]从数据库中检索,并保存为表示图像的文章的自定义字段2。因此,在数据库检索和关键函数调用之间使用unlink(),表示缩略图文件名的值不经过任何清理或检查。如果该值在保存到数据库之前也没有经过任何安全措施,我们将在下一个代码列表中看到情况,我们有一个二阶任意文件删除漏洞。

未分类

WordPress内核中一个任意文件删除漏洞,可导致攻击者执行任意代码
此代码片段/wp-admin/post.php代表了附件中属于附件的缩略图的文件名如何保存到数据库中。在从保存在$_POST[‘thumb’]数据库中的用户输入中检索和保存到数据库wp_update_attachment_metadata()之间没有任何安全措施,以确保该值代表正在编辑的附件的缩略图。$_POST[‘thumb’]对于任何文件的路径,这个值可以保存到WordPress上传目录的相对路径中,当附件被删除时,该文件将被删除,如第一列表中所示。

临时修复程序

在编写此篇文章时,此漏洞在WordPress内核中仍未被修复。正因为这样,我们开发了一个临时修复程序。通过将修复程序添加到functions.php当前活动的主题/子主题文件中,可以将修复程序集成到现有的WordPress安装中。

未分类

WordPress内核中一个任意文件删除漏洞,可导致攻击者执行任意代码
所有提供的修复程序都会挂接到wp_update_attachement_metadata()调用中,并确保为元值提供的数据thumb不包含任何使路径成为可能的部分。因此,不能删除与安全相关的任何文件。

我们所提供的修复方案属于临时修复,以防止攻击。我们无法监督WordPress插件的所有可能的向后兼容性问题,因此建议您谨慎的对WordPress文件进行任何修改。

时间线

未分类

总结

在这文章中,我们介绍了WordPress内核中引入了一个任意文件删除漏洞,它允许任何具有作者权限的用户完全接管WordPress网站,并在服务器上执行任意代码。该漏洞去年已报告给WordPress安全团队,但在编写本文时仍然没有作任何修复。

为了提高对此漏洞的认识,我们决定发布一些细节和修复程序。使用我们的安全分析解决方案可以轻松发现漏洞,我们确信这个问题已经被许多研究人员所了解。尽管用户帐户的需求阻止了任意WordPress站点的大规模开发,但共享多个用户帐户的WordPress站点应该应用此修复程序。

让一个端口同时做两件事:http/https和ssh

相信很多人都在YY:能不能让80端口分析连接协议,如果是http协议就让服务器交给http服务程序(如Apache、Nginx等)处理,如果是ssh协议就交给ssh服务程序(如OpenSSH Server)处理呢?

答案显然是有的。

首先,配置http服务程序监听8080端口或者让https服务监听8443端口,配置ssh服务程序监听22端口。具体不再赘述,如果这都不懂就不用往下看了,因为肯定会搞不定的。

然后,安装一个叫haproxy的强大工具。步骤如下。

下载源代码:

wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.16.tar.gz

查看当前内核版本:

uname -r

然后进入目录编译安装:

cd haproxy-1.4.16
make TARGET=linux26 PREFIX=/usr/local/blog.creke.net/haproxy
make install PREFIX=/usr/local/blog.creke.net/haproxy

其中,第二行的“TARGET”参数要和内核版本一致。第二、三行的“PREFIX”是安装位置。

最后,配置haproxy。

如果要监听80端口,检测到http协议就转发给8080端口使用HTTP,否则转发给22端口使用ssh。配置如下:

#By http://blog.creke.net/
global 
    maxconn 5120  
    chroot /usr/local/blog.creke.net/haproxy   
    daemon 
    quiet 
    nbproc 2 
    pidfile /usr/local/blog.creke.net/haproxy/haproxy.pid
defaults 
    timeout connect 5s 
    timeout client 50s 
    timeout server 20s
listen http 
    bind :80 
    timeout client 1h 
    tcp-request inspect-delay 2s 
    acl is_http req_proto_http 
    tcp-request content accept if is_http 
    server server-http :8080 
    use_backend ssh if !is_http
backend ssh 
    mode tcp 
    timeout server 1h 
    server server-ssh :22

如果还有监听443端口,检测到https协议就转发到8443端口使用HTTPS,否则转发给22端口使用ssh。则配置如下:

global 
    maxconn 5120  
    chroot /usr/local/blog.creke.net/haproxy   
    daemon 
    quiet 
    nbproc 2 
    pidfile /usr/local/blog.creke.net/haproxy/haproxy.pid
defaults 
    timeout connect 5s 
    timeout client 50s 
    timeout server 20s
listen https 
    bind :443 
    timeout client 1h 
    tcp-request inspect-delay 2s 
    acl is_ssl req_ssl_ver 2:3.1 
    tcp-request content accept if is_ssl 
    server server-https :8443 
    use_backend ssh if !is_ssl
backend ssh 
    mode tcp 
    timeout server 1h 
    server server-ssh :22

把内容保存为“/usr/local/blog.creke.net/haproxy/etc/haproxy.conf”,执行命令:

/usr/local/blog.creke.net/haproxy/sbin/haproxy -f /usr/local/blog.creke.net/haproxy/etc/haproxy.conf

即可运行。

好了,大家应该可以举一反三,起码也可以依葫芦画瓢吧。