HTTPS 证书介绍和获取

Geotrust:
优点: 非常便宜
缺点: 品牌比较弱, 不兼容安卓4.x及以下平台,于是签发了equifax Secure CA的交叉认证导致证书多了一级
使用者: 搜狐 weixin.qq.com(微信公众号平台等)

globalsign:
优点: 性价比高, 天然三级, 兼容性好
缺点: 品牌稍弱, 不支持安卓2.3和之前的版本, XP需要更新根证书后才支持(系统自动完成的) 黑历史让人担忧 (2016.10出现过错误吊销中间证书的严重故障 )
使用者: 京东 淘宝 腾讯(xw.qq.com等 www.qq.com和news.qq.com 也在这张证书但是暂未提供https服务)

verisign:
优点: 品牌强大 兼容性好 可以直接使用三级 支持ECC加密性能更优
缺点: 贵 支持ECC双证书会更贵! 不支持安卓2.3和之前的版本
使用者: 搜狗 爱奇艺 百度 腾讯灯塔平台(beacon.qq.com,广告营销大数据分析等)

总结:
geotrust 的兼容性是通过交叉认证实现的,这导致每次请求都需要发多一张中间证书,这会带来一定的性能损失
除了黑历史, 京东 淘宝 腾讯都选择了globalsign, 除了性价比的因素,对方天然的三级证书优势也很明显
verisign 品牌悠久, 兼容性好,但是价格就不那么美好了,是个保守而稳定的选择

当然,以上都是要钱的,对于个人用户,选择免费证书是更好的选择,比如: https://letsencrypt.org/

HTTPS 部署和优化

本文主要介绍HTTPS 部署和优化, 构思中包括以下内容:

1. 证书的介绍和获取
1) 商业证书
介绍市面上主流的geotrust globalsign verisign三家证书签发机构
2) 免费证书
介绍Let’s Encrypt这家了不起的免费证书颁发机构
2. nginx start up配置
3. spdy 和 http2.0 支持
4. ciphers suite的选择
5. 为何不建议开启ocsp
6. HTTPS优化
7. ie6的支持

先挖个坑,以后慢慢填

如何迁移域名和投诉35互联

国内的一些域名商比较恶心,比如35互联.

当时我的域名是通过一个代理买的,我获得的权限就是一个DNS管理平台,可以指一下NS A CNAME等记录,但是域名资料信息什么的是没有账号修改的
刚好今年碰到域名实名,想着干脆就迁走吧,于是发信给35互联的客服咨询如何迁出.
本来做好了签名/身份证/转移书等邮寄到厦门的打算了,没想到35互联的客服压根就不想跟我谈,只是让我去找代理,但是代理也不管这事了…

这个时候就怒了啊,搜了下资料,被35互联这个大坑惹怒的人还真不少,投诉资料也挺多的,我顺便也科普下:
步骤1. 使用域名登记资料里边的邮箱, 正式发信给35互联客服,要求迁出,要求提供迁出密码
步骤2. 等待5个工作日,35互联肯定不会给你迁出密码的,要么让你找代理,要么让你邮寄资料之类的
步骤3. 上国际域名管理组织投诉去, 这里填表: https://forms.icann.org/en/resources/compliance/complaints/transfer/form
步骤4. 等上2-3天,icann.org 会邮件给你,要你确认是否迁出,并提供下原域名注册商不配合的证据(步骤1的邮件即可)
步骤5. 嗯,过几天,35互联的客服就会乖乖把迁出密码给你了

需要谨记,按照国际域名管理组织的规定, 只要你是域名拥有者,就有资格迁出域名和获取域名迁出码,不需要邮寄隐私资料,更加不需要找什么代理去谈

syslog-ng 的一些格式

1. syslog-ng 是支持模板的,可以自由定义格式,比如
destination d_access {
file(“/opt/itc/syslog-ng/logs/$PROGRAM/$YEAR$MONTH$DAY/access_log”
create_dirs(yes)
dir_owner(“nobody”)
dir_group(“nobody”)
dir_perm(0755)
owner(“nobody”)
group(“nobody”)
perm(0644)
template(“${HOUR}:${MIN}:${SEC} ${HOST} ${PROGRAM} ${MSG}\n”)
);
};

2. 这个例子又刚好会触发一个小窍门,一般加了template的会发现数据丢了第一项,这是因为:
syslog-ng 会把第一列 当做是 $PROGRAM ,之后的那些内容才是 MSG

3. 那么,我想加PROGRAM 让syslog-ng 识别,在收集日志的机器分散出来怎么办? 在source里边定义就好
source s_app {
file(“/opt/itc/nginx/logs/app_access.log”
program_override(“app.4os.org”)
flags(no-parse)
);
};

这个例子里边,就会在原始日志里边自动添加一列 app.4os.org 作为PROGRAM到日志里边去

4. 总结下,实际上,没有template的默认日志格式是怎样的?
${ISODATE} ${HOST} ${PROGRAM} ${MSG}\n

其中日期函数跟定义有关,默认为iso

gcc 与 ld 的lib顺序

事情是这样子的,有个编译出来的.so文件,死活在找一个诡异版本的libcrypto.so,而我检查过环境变量和编译参数还有ldconfig,并未包含这些东西
绕了一个大圈子,查找编译文件并未包含这些路径,最后在简化测试的时候发现了问题所在
#ld -shared -o test.so -lcrypto
极为简单的一个测试,发现在故障机器上编译出来的.so还是包含了错误的libcrypto.so
strace下发现了问题,这是因为ld有个依赖顺序:
“/usr/x86_64-redhat-linux/lib64/”,”/usr/local/lib64/”, “/lib64/”,/usr/lib64/, /usr/x86_64-redhat-linux/lib/ , /lib/ , /usr/lib/

而刚巧,这机器在/usr/local/lib64/被不知名土人放了个错误版本的libcrypto.so

另外,补充下,如果用了-L参数指定路径,那么这个路径则是最优先的

而LD_LIBRARY_PATH 则是执行时查找的动态链接库位置,跟ldconfig功能一样,不影响编译,因此以上例子查找ldconfig是不必要的

而最重要的是解决问题的思路,分割问题==>缩小范围==>定位问题!

python 替换\n

一般来说,python可以通过strip() 或者replace(‘\n’,”)的方式来替换掉\n 字符

不过改动某个功能代码的时候异常的发现两种替换方式都失败了,debug定位了下,发现数据是通过readlines()的方式读取进来的
而readlines 会自动的把字符中的\r\n 更改为 \\r\\n,从而导致替换失败

嗯,如果是readlines的数据,只能用replace(‘\\n’,”)了
当然,不要用readlines比较好

infinidb 出现导入错误:ERROR 122

ERROR 122 (HY000): PM1 : Bulkload Read (thread 0) Failed for Table cdn. Terminating this job.

#perror 122
OS error code 122: Disk quota exceeded
MySQL error code 122: Internal (unspecified) error in handler

内部错误,没有特别好处理的办法,查了下,有日本文档介绍通过取消batchinsert设置来定位问题的,不过我测试失败
调试过程中发现取消了infinidb_use_import_for_batchinsert则可以正常导入,另外通过笨办法分割导入定位到了出错数据,原来是原始数据的某一列中包含了”\r\n”的内容,而我的导入方式是以\n 作为结尾的

附上日本文档地址和方法:
mysql> SELECT @@infinidb_use_import_for_batchinsert; — これがONだとLOAD DATA INFILEを/usr/local/Calpont/bin/cpimportにマップしてくれるので無効にする。
+—————————————+
| @@infinidb_use_import_for_batchinsert |
+—————————————+
| 1 |
+—————————————+
1 row in set (0.00 sec)

mysql> SET SESSION infinidb_use_import_for_batchinsert= 0;
Query OK, 0 rows affected (0.00 sec)

mysql> LOAD DATA INFILE ‘/data/tmp/fifo’ INTO TABLE vegelog;
Query OK, 17208325 rows affected, 2076 warnings (5 min 35.09 sec)
Records: 17208325 Deleted: 0 Skipped: 0 Warnings: 2050

mysql> show warnings;
+———+——+——————————————————————————–+
| Level | Code | Message |
+———+——+——————————————————————————–+
| Warning | 1262 | Row 5397 was truncated; it contained more data than there were input columns |
| Warning | 1262 | Row 5406 was truncated; it contained more data than there were input columns |
| Warning | 1262 | Row 59575 was truncated; it contained more data than there were input columns |
..
| Warning | 1261 | Row 329176 doesn’t contain data for all columns |
| Warning | 1261 | Row 329176 doesn’t contain data for all columns |
| Warning | 1261 | Row 329176 doesn’t contain data for all columns |
+———+——+——————————————————————————–+
64 rows in set (0.00 sec)

edns 与 8.8.8.8 DNS Cache

测试bind-9.8.1-P1 的edns的时候发现,google DNS解析的结果一直在跳,有时候在电信区,有时候在us区

于是给它打了第一个patch,让query log 支持edns的client subnet显示,便于排查

筛选下日志,发现很多edns请求不在我们的ecs ACL范围内,最终落到了google DNS IP 所在的us区域,推测应该是这个造成了google DNS 的错误缓存

于是,把ecs的default区域加入拦截

view "default_ecs" {
match-clients { ecs 0.0.0.0/0; ecs ::/0;};
... ...
};

这样一来,的确是响应了edns请求,结果却是更多的出现了default 区的结果(热数据),或者在client所属区域和default区结果之间跳动(冷数据)

听包,发现google DNS发送过来的请求Scope Netmask 都是0,如果ecs ACL拦截不成功到了default_ecs区域,最终被ecs 0.0.0.0/0; ecs ::/0; 拦截成功,导致返回的Scope Netmask变成了0

Scope Netmask 变为0意味着什么? 意味着这个结果集有效并且范围最大,从而污染所有的subnet client结果集

目前来看,只能给它打个patch

让client subnet 到了default区域的结果集Scope Netmask 为起address netmask长度,控制结果集的有效范围

测试下,把某个网段故意从ecs ACL挪走,让default ecs拦截看看响应是否是我们期待的

正常网段的请求,返回我们ecs ACL的Netmask

上线测试,目前服务正常

 

附上edns 文档,非常重要:
https://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-01
http://noops.me/?p=653

以上的显示EDNS 的代码存在bug, 需要初始化

char edbuf[ISC_NETADDR_FORMATSIZE] = { 0 };

这里需要特别解释下 为什么char数组初始化使用 {0}, 这里有个解释

it’s a C-style cast. That is, it converts 0 (which is a literal of type int) to char (the \0 character). That cast could have been avoided entirely by simply using the ‘\0’ literal.

测试char = 0; 的时候打印出来直接是null, 从stackoverflow的解释看是这么回事

https://stackoverflow.com/questions/10004297/what-does-char0-mean-in-c

win7 一直在检查更新的问题

最近新装win7后,发现windows更新一直显示在检查更新,cpu很高,即使等待非常长的时间后也无法获取更新

这是因为微软升级了windows update的更新机制,如果是全新安装的win7,或者长时间未更新的win7系统,则需要先打两个补丁来获取更新

KB3020369 April 2015 servicing stack update for Windows 7 and Windows Server 2008 R2
KB3172605 July 2016 update rollup for Windows 7 SP1 and Windows Server 2008 R2 SP1

详情可以查看微软的官方链接,补丁也建议只从微软官方下载:
https://support.microsoft.com/en-us/kb/3200747

macOS sierra QQ 4.x 解决截图失败问题

由于MAC QQ团队众所周知的反人类设计团队问题,我一贯是坚持使用旧的4.2.5版本

升级到macOS sierra,也就是mac 10.12版本之后,4.2.5的macQQ截图功能就失效了

解决办法比较简单: 从官网下载最新版的macQQ,当前是5.2.0
下载后双击,点击同意协议,直到出现这个界面,但不要继续拖动图标进行安装
qq1

打开finder,找到设备->QQ,对着QQ.app右键->显示包内容,进入 Contents/Library/LoginItems
qq2

拷贝文件:JietuMac.app和QQPlatform.app到应用程序-QQ 的/Contents/Library/LoginItems 目录(进入目录方法也是类似),拷贝过去后把JietuMac.app改名为ScreenCapture.app(原来的文件直接删除或者改名)

qq3

到这一步后打开QQ程序,左上角菜单,QQ-偏好设置-截屏设置-开启设置面板,会提示你进入刚才拷贝的目录
qq4
这个时候依次双击拷贝进来的文件QQPlatform.app和ScreenCapture.app(从JietuMac.app改名而来),会提示让你确认是否打开

执行完这一步,macQQ截图功能就正式可用了