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截图功能就正式可用了

nginx proxy模式下502 bad gateway 问题

并发测试的时候发现nginx 502 bad gateway 了,看了下日志发现很多upstream Cannot assign requested address的记录
connect() to 192.168.89.170:80 failed (99: Cannot assign requested address) while connecting to upstream

正常判断应该是端口不够用了
不过,我确实开启了: net.ipv4.tcp_tw_recycle = 1 和 net.ipv4.tcp_tw_reuse = 1两个参数
理论上应该可以把timewait 端口重用,查了下这个参数跟tcp_timestamps有关(http://blog.sina.com.cn/s/blog_781b0c850100znjd.html)

if (tmp_opt.saw_tstamp &&
tcp_death_row.sysctl_tw_recycle &&
(dst = inet_csk_route_req(sk, req)) != NULL &&
(peer = rt_get_peer((struct rtable *)dst)) != NULL &&
peer->v4daddr == saddr) {
if (get_seconds() < peer->tcp_ts_stamp + TCP_PAWS_MSL &&
(s32)(peer->tcp_ts – req->ts_recent) >
TCP_PAWS_WINDOW) {
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
goto drop_and_release;
}
}

tmp_opt.saw_tstamp:该socket支持tcp_timestamp
sysctl_tw_recycle:本机系统开启tcp_tw_recycle选项
TCP_PAWS_MSL:60s,该条件判断表示该源ip的上次tcp通讯发生在60s内
TCP_PAWS_WINDOW:1,该条件判断表示该源ip的上次tcp通讯的timestamp 大于 本次tcp

因此: 应该在proxy端和后端都开启net.ipv4.tcp_timestamps=1

网卡LACP聚合配置

本文主要介绍多网卡lacp 聚合模式配置,即mode=4模式下RHEL6 bonding 和 RHEL7 team的配置

此模式需要在交换机做配置LACP聚合,具体参考交换机设置
配置范例以双网卡eth0 eth1为例,多网卡类推

RHEL6 配置

1.新增配置文件/etc/modprobe.d/bonding.conf,内容如下

alias bond0 bonding
options bond0 miimon=100 mode=4 lacp_rate=1 xmit_hash_policy=layer3+4

2.更改网卡配置

#/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

#/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

#/etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.1.233
NETMASK=255.255.255.0
NETWORK=192.168.1.0
GATEWAY=192.168.1.254

3.重启网络

service network restart

4.注意点: 参见最后附录

 

RHEL7 配置

1. 修改网卡配置

# /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=”eth0″
ONBOOT=yes
UUID=”原来的UUID”
DEVICETYPE=TeamPort
TEAM_MASTER=team1

#/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
DEVICETYPE=TeamPort
UUID=”原来的UUID”
ONBOOT=yes
TEAM_MASTER=team1

新增配置: /etc/sysconfig/network-scripts/ifcfg-team1
DEVICE=team1
DEVICETYPE=Team
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.1.23
PREFIX=24
DEFROUTE=no
TEAM_CONFIG='{“runner”: {“name”:”lacp”, “active”:true, “fast_rate”:true, “tx_hash”:[“ipv4”], “ports”:{“eth0”:{}, “eth1”:{}}}}’
MTU=1476

2. 重新启动机器,是的,重新启动机器

问题研究

 
1. RHEL6网卡in能分摊到不同网卡,但是out只走一个网卡
检查/proc/net/bonding/bond0 文件,看看 Transmit Hash Policy 是否正确,一般layer2 在内网测试可能会有问题
需要配置xmit_hash_policy=layer3+4 或者 xmit_hash_policy=layer2+3

2. RHEL7 systetemctl restart network 网卡不通
恩,是的,重启机器吧

哪里买 mac air

2014款的macbook air发布了,作为macbook里边最轻便的机器,满足办公和日常娱乐是没有问题的


macbook-air-holiday-hero-xl-2015

带来了intel最新的i5和i7处理器,也带来了期待已久的背光键盘

那么,作为apple fans当然是入手一台,下边比较下大陆,香港,美国的价格

大陆:
cn_macbook

香港:
hk_macbook

美国:
us_macbook
以13″低配为例,简单换算下:

大陆:  6988RMB

香港:  7488HK$ 约合 6000RMB不到

美国:  999US$   约合 6300RMB

可见,在香港购买是最合算的,分别比美国和大陆购买便宜了1000和300元左右(差价已经比11年的时候小了很多,依然是值得购买的)

so,apple fans,去HK 买一台吧!

以下是HK 苹果专卖店的推荐地址,比较建议去中环IFC Mall购买,其实大概到了2015年年初,就可以去买iphone6了

地址: 國際金融中心商場香港中環金融街 8 號

电话: 香港3972-1500

交通指引: 東涌線或機場快線前往香港站;港島線及荃灣線前往中環站,Apple Store 位於 ifc mall 1 樓及 2 樓最東面,鄰近中環碼頭