PHPor 的Blog – 第26页

关于ssl证书提供商

缘起：

我从赛门铁克买的证书是Verisign签发的，后来说是证书有问题，需要重签，拿到的证书就成了DigiCert签发的了；而且邮件里面给出的证书的安装配置和使用方案，请参考：

https://www.itrus.cn/service_13.html 这个地址是天威诚信的网站。

那么， Verisign / Symantec / DigiCert / 天威诚信都是啥关系？

天威诚信是Symantes中国大陆地区的首要合作伙伴。

2010年8月，赛门铁克收购VeriSign，VeriSign认证服务现均由赛门铁克提供。赛门铁克重点在2012年4月对VeriSign的产品名称和品牌标识进行变更;

2017年8月份，赛门铁克把web安全业务卖给了DigiCert , 并占有DigiCert 30% 的普通股： http://www.cnbeta.com/articles/tech/637909.htm

更多： GeoTrust 似乎也是重要的SSL证书提供商，那么和上述的机构是否也有关系呢？

参考： https://baike.baidu.com/item/verisign/8794893

VeriSign 是全球最大的数字证书颁发机构，于 2006 年 9 月以 1.25 亿美元完成收购 GeoTrust ，当时 GeoTrust 约占全球 25% 市场分额。VeriSign通过与中国内地数字认证服务商天威诚信合作共同推进数字证书业务在国内的发展

中国也有根CA了：

中国金融认证中心(CFCA)证书，由中国数字证书认证机构自主研发，纯国产证书。*注: CFCA服务器证书目前不支持苹果iOS 10.1及10.1以前的版本，不支持安卓6.0以前的版本

阿里云购买证书似乎便宜些：（方便比价）

https://common-buy.aliyun.com/?spm=5176.7968328.1120760.1.67f91232806dKi&commodityCode=cas#/buy

https://www.aliyun.com/product/cas?utm_content=se_1550552

参考：

http://www.ert7.com/symantecs.html

https://marketrealist.com/2017/08/why-symantec-sold-its-web-security-business-to-digicert

http://www.cnbeta.com/articles/soft/636841.htm

http://tech.sina.com.cn/roll/2017-03-28/doc-ifycspxp0209037.shtml

https://www.digicert.com/blog/digicert-to-acquire-symantec-website-security-business/

https://www.symantec.com/about/newsroom/press-releases/2017/symantec_0802_01

http://www.cnbeta.com/articles/tech/630921.htm

ssh远程copy目录到远程

阿里云redis数据迁移

一般来讲，如果我们要从自建的redia迁移到阿里的redis，可以采用aof文件的办法，通过：

CONFIG SET appendonly yes

1	CONFIG SET appendonly yes

创建一个aof文件，也可能你的配置下本来就有这个文件，然后通过：

tail -n $big_number -f  appendonly.aof |redis-cli target_host target_port

1	tail -n $big_number -f appendonly.aof \|redis-cli target_host target_port

其中 $big_number 是一个足够大的数，保证tail是从文件的第一行开始的，如此，则可以保证源redis和目标redis的数据是一致的，代码上修改完配置后，源redis不再有写入，即可废掉源redis

由于阿里云的redis没有一个可以供我们tail的aof文件，所以，没法通过上述办法将阿里云redis数据平滑迁移到本地（抑或是阿里云其他）redis实例，不过也可以有不太平滑的办法的。

阿里云redis的备份其实就是一个rdb文件，只需要：

方案一：

停掉redis
创建redis备份（这个在阿里云控制台是支持的）
下载备份
根据备份启动redis实例
生成一个aof文件
cat aof | redis-cli target_host target_port 即可
如果需要在迁移的同时修改db号，即：将db 1 中的数据迁移到db 2中，可参考： https://phpor.net/blog/post/5614
该方案需要暂停服务的

方案二：

使用工具 https://github.com/vipshop/redis-migrate-tool https://q.cnblogs.com/q/93181/
该方案没法将源db修改成目标的其他db

方案三：

使用redis-port

bash 之echo vs printf

没有发现如何仅仅通过echo 直接输出 ‘-e’ 的方法， printf则可以 — 使得不再继续解析更多选项。

If you want to literally print the string “-e”, you will have difficulties doing it with echo. I faced such a problem recently while writing a script.

I had to use prinf to be able to print the literal string “-e”.

bash 之 echo -e

示例：

#echo -e "a\nb"
a
b

#echo -e "a\nb"

如果我仅仅想输出 ‘-e’ 呢？如何echo 呢？

#echo -e

#echo -e

这个是不会有任何输出的，当然，你可能马上就发现问题了；不过，有些情况下，你想echo的东西是预先不知道的，实在程序运行时生成的，万一生成了 ‘-e’ ，你将看不到 ‘-e’ ,而且还影响了程序的行为，如何避免呢？

gnocchi-api 访问慢的问题

gnocchi-api 访问基本在10s +， why ?

gnocchi-api 使用了 wsgiref , wsgiref 使用了 :

/usr/bin/gnocchi-api:

server = wss.make_server(args.host, args.port, build_wsgi_app())

1	server = wss.make_server(args.host, args.port, build_wsgi_app())

/usr/lib64/python2.7/wsgiref/simple_server.py :

(这里提到了个REMOTE_HOST的环境变量，含义就是“REMOTE_ADDR 对应的域名”，而 address_string() 的命名也是ip地址对应的域名的意思，因为绝大部分的ip地址是反解不到域名的，所以，这个逻辑基本可以注释掉，不过，直接修改人家的代码不大好）

然而上面的 WSGIRequestHandler 基本上会执行到get_environ() , 进而执行到 BaseHTTPServer.py 中的 self.address_string() ，如下：

address_string() 函数又调用了 /usr/lib64/python2.7/socket.py 中的 getfqdn(), 如下：

然后就肯定会执行到gethostbtaddr() 了，该函数的具体实现又是什么逻辑呢？ socket.py import了 _socket 模块中的所有函数，而gethostbyaddr()正是_socket 模块实现的，_socket 模块的实现见： /usr/lib64/python2.7/lib-dynload/_socketmodule.so ，可见，这是一个c实现的so文件，稍后再看：

测试发现，该函数当遇到IP地址时，肯定会做一次反向地址解析，反向地址解析不是所有dns都能支持的很好的，有些能快速返回，有些却不能（具体原因，稍后再查），比如：公网地址的反向地址解析可以很快返回，私网地址的反向地址解析就很慢

解决办法：

办法一：在 dns 上给自己的IP地址添加反向地址解析，这样反向地址解析就可以很快; 给每个IP地址都添加反向地址解析的话，比较麻烦，最好能有一个更好的办法，让某一类IP地址能直接返回错误，或返回一个自定义的域名；这个办法的优点是： 不需要修改程序； 如果搞不定dns，那就修改程序吧

办法二：修改/usr/lib64/python2.7/BaseHTTPServer.py ，在 address_string() 中直接返回host，而不进行socket.getfqdn(host) 的调用

办法三：修改 /usr/lib64/python2.7/socket.py 中的 getfqdn() 函数，对于ip地址的情况，不再调用 gethostbyaddr()

办法四：其实，不是特别有信心的话，不要修改的太底层，没准儿影响到别的程序的；更好的办法是：

在 /usr/bin/gnocchi-api 中wss.make_server(…) 时，提供了三个参数，还有两个参数是可以定制的，我们可以自己在 /usr/bin/gnocchi-api 中实现一个 MyWSGIRequestHandler ，继承自./simple_server.py 中的WSGIRequestHandler ，然后覆盖其中的address_string() 方法即可

按照办法四修改后的 /usr/bin/gnocchi-api 如下：

#!/usr/bin/python2
#PBR Generated from u'wsgi_scripts'

import threading

from gnocchi.rest.app import build_wsgi_app
from wsgiref.simple_server import WSGIRequestHandler
class GnocchiWSGIRequestHandler(WSGIRequestHandler):
    def address_string(self):
        return self.client_address[0]

if __name__ == "__main__":
    import argparse
    import socket
    import sys
    import wsgiref.simple_server as wss

    my_ip = socket.gethostbyname(socket.gethostname())

    parser = argparse.ArgumentParser(
        description=build_wsgi_app.__doc__,
        formatter_class=argparse.ArgumentDefaultsHelpFormatter,
        usage='%(prog)s [-h] [--port PORT] [--host IP] -- [passed options]')
    parser.add_argument('--port', '-p', type=int, default=8041,
                        help='TCP port to listen on')
    parser.add_argument('--host', '-b', default='',
                        help='IP to bind the server to')
    parser.add_argument('args',
                        nargs=argparse.REMAINDER,
                        metavar='-- [passed options]',
                        help="'--' is the separator of the arguments used "
                        "to start the WSGI server and the arguments passed "
                        "to the WSGI application.")
    args = parser.parse_args()
    if args.args:
        if args.args[0] == '--':
            args.args.pop(0)
        else:
            parser.error("unrecognized arguments: %s" % ' '.join(args.args))
    sys.argv[1:] = args.args
    server = wss.make_server(args.host, args.port, build_wsgi_app(), handler_class = GnocchiWSGIRequestHandler)

    print("*" * 80)
    print("STARTING test server gnocchi.rest.app.build_wsgi_app")
    url = "http://%s:%d/" % (server.server_name, server.server_port)
    print("Available at %s" % url)
    print("DANGER! For testing only, do not use in production")
    print("*" * 80)
    sys.stdout.flush()

    server.serve_forever()
else:
    application = None
    app_lock = threading.Lock()

    with app_lock:
        if application is None:
            application = build_wsgi_app()

#!/usr/bin/python2

#PBR Generated from u'wsgi_scripts'

import threading

from gnocchi.rest.app import build_wsgi_app

from wsgiref.simple_server import WSGIRequestHandler

class GnocchiWSGIRequestHandler(WSGIRequestHandler):

def address_string(self):

return self.client_address[0]

if __name__ == "__main__":

import argparse

import socket

import sys

import wsgiref.simple_server as wss

my_ip = socket.gethostbyname(socket.gethostname())

parser = argparse.ArgumentParser(

description=build_wsgi_app.__doc__,

formatter_class=argparse.ArgumentDefaultsHelpFormatter,

usage='%(prog)s [-h] [--port PORT] [--host IP] -- [passed options]')

parser.add_argument('--port', '-p', type=int, default=8041,

help='TCP port to listen on')

parser.add_argument('--host', '-b', default='',

help='IP to bind the server to')

parser.add_argument('args',

nargs=argparse.REMAINDER,

metavar='-- [passed options]',

help="'--' is the separator of the arguments used "

"to start the WSGI server and the arguments passed "

"to the WSGI application.")

args = parser.parse_args()

if args.args:

if args.args[0] == '--':

args.args.pop(0)

else:

parser.error("unrecognized arguments: %s" % ' '.join(args.args))

sys.argv[1:] = args.args

server = wss.make_server(args.host, args.port, build_wsgi_app(), handler_class = GnocchiWSGIRequestHandler)

print("*" * 80)

print("STARTING test server gnocchi.rest.app.build_wsgi_app")

url = "http://%s:%d/" % (server.server_name, server.server_port)

print("Available at %s" % url)

print("DANGER! For testing only, do not use in production")

print("*" * 80)

sys.stdout.flush()

server.serve_forever()

else:

application = None

app_lock = threading.Lock()

with app_lock:

if application is None:

application = build_wsgi_app()

测试发现，访问确实快多了，不再感觉到延迟了

docker-init in bash

把下面脚本当做容器的init进程：

#!/bin/bash
# kill all process except pid=1

export TZ=UTC-8

trap "quit; exit " 1 2 3 15

function log() {
        echo $(date +"%F %T") "$@"
}

function quit() {
        while :; do
                local pid_info=$(ps -axo pid,ppid,comm --no-headers|awk '$1 != 1 {print $0}')
                [[ $pid_info == "" ]] && break
                local succ=0
                while read pid ppid comm; do
                        if kill $pid &>/dev/null; then
                                ((succ++))
                                log "$(printf '%-64s[%s]' "killing pid $pid(ppid: $ppid, comm: $comm)" succ)"
                        else
                                log "$(printf '%-64s[%s]' "killing pid $pid(ppid: $ppid, comm: $comm)" fail)"
                        fi
                done < <(echo "$pid_info")
                [[ $succ == 0 ]] && break
                sleep 1
        done
}


while read line; do
        log "$line"
done

#!/bin/bash

# kill all process except pid=1

export TZ=UTC-8

trap "quit; exit " 1 2 3 15

function log() {

echo $(date +"%F %T") "$@"

}

function quit() {

while :; do

local pid_info=$(ps -axo pid,ppid,comm --no-headers|awk '$1 != 1 {print $0}')

[[ $pid_info == "" ]] && break

local succ=0

while read pid ppid comm; do

if kill $pid &>/dev/null; then

((succ++))

log "$(printf '%-64s[%s]' "killing pid $pid(ppid: $ppid, comm: $comm)" succ)"

else

log "$(printf '%-64s[%s]' "killing pid $pid(ppid: $ppid, comm: $comm)" fail)"

done < <(echo "$pid_info")

[[ $succ == 0 ]] && break

sleep 1

done

}

while read line; do

log "$line"

done

知识点：

while循环中修改外部的环境变量，则不能使用管道的方式给while提供数据，这样的话，while 就是在新的子shell中执行的，不会影响到当前shell，所以：
1. 使用了标准输入的重定向
2. 使用了 <($cmd) 的方式
为了让字符串中连续的空格被保留，参数传递时多要通过双引号引上，即使是 $(cmd) 产生的字符串也要整个用双引号引上，当然，此时的双引号比较特殊，因为此时的双引号可以套双引号而不需要转义，示例： (注意下面几种双引号中嵌套单引号的的区别）

注意：

这个init进程是bash做的，如果docker attach的话，不管是ctrl-d退出还是ctrl-c退出，都会导致init进程终止，容器退出
脚本中的while循环最初想到的是通过sleep实现暂停的，但是考虑到sleep会产生一个额外的进程，不好看，于是选择了read;
注：后来发现，使用read有一定好处，bash处理信号需要注意的是，在执行外部命令（如： sleep）时不能实时处理信号，只有在外部命令结束后才能处理信号；而read虽然也是阻塞的，但是能实时处理信号

linux文件系统评估之inode – it_arch_notes – 博客园

https://www.cnblogs.com/wuhuiyuan/p/linux-filesystem-inodes.html

ext*文件系统的inode数量是预先定义好的，但是xfs的不是，xfs文件系统比较能很好地平衡inode和磁盘空间的使用

时延与带宽之间的关系

带宽计算公式为：带宽=时钟频率*总线位数/8

对于网线来讲，总线位数等于1，而且公式里的带宽单位显然是byte/s

时延包括好多方面

仅从链路上的传输时延来讲，仅仅和信号在介质上的传播速度有关系，和带宽没有关心

为什么给人的感觉是带宽越大，延迟越小呢？我觉得，更大的带宽可以在大数据量时降低排队时延，进而降低总体时延；如果设备没有任何负载，从结点A发送到结点B一个数据包的时延应该和A、B之间的带宽没有一毛钱关系。

又是什么影响带宽的呢？

我觉得带宽是由频率决定的，单位时间内，产生的波峰和波谷越多，就意味着信息量越大，也就是带宽越大

带宽和延迟之间的关系：

当数据量很小时，延迟基本会稳定在某个值左右。随着数据量的变大，延迟也会变大；就好比从北京开车去广州，高速上车越多，花费的时间也就越多，尽管还没达到最大吞吐量，延迟已经很厉害了。当然，如果你走土路，可能和车多少关系也不大，这个就是介质问题。

所以，高带宽和低延迟需求要分开考虑，尽量使用不同的网络。

参考： http://m.blog.csdn.net/u013830021/article/details/73648091

http://m.blog.csdn.net/xchbx/article/details/11537951

文件系统之 inode篇

缘起：

20T的1亿个小文件存放在xfs的文件系统中会存在inode被用光（但是存储空间还有很大空闲）的问题吗？

测试：

df -i 可以看到可用、已用inode数量，一般来讲，mkfs的时候，会划分 x% 的空间存放inode的，可用inode数量是按照文件个数计算的，不是按照占用空间计算的，如：

500GB的磁盘，格式化为xfs后，可以使用的inode数量约 2.6亿；那么1GB的磁盘格式化为xfs后，可用inode数量为 2.6亿/500 ~= 50万吗？测试如下：

确实，1GB默认可以存放约52万个文件，注意：目录也是占用inode的，而且也不可能把所有文件都放在一个目录的，所以真正计算inode的话，还需要把目录的数量算上；按照每个目录100个文件计算的话，50万个文件就需要5k个目录（可以忽略不计了）；其实不全对，5k个目录放在一个父目录下也不科学，为了保证每个目录最多100个的话，还要分到50个父目录里面，额.. 也没有多少目录

按照上面的公式计算： 20T/1G*50w ~= 1000亿个文件，不少了

当然，如果还不够的话，格式化的时候可以指定更大的inode数量

计算：

10亿个文件，打散到N个目录中，每个目录的子目录（文件）数量不超过100个，需要多少级子目录？

100^x > 10亿，x最少值为 x>=5 ，就是说 5层目录就够了

其实，xfs是个比较只能的文件系统，没有固定大小的inode区域，随着磁盘的使用，inode的总数量也在变化，基本不会出现inode已用光，但是存储空间很空闲很多的情况