sysdig是个小巧的系统诊断工具。一方面可以帮助排查应用的瓶颈，另外一方面也可做异常排查的诊断工具观察进程的一些行为。以前一直有个问题困扰着我，大量老机房下线时，基础的DNS服务下线非常麻烦。虽然能在dns服务器上抓包查看client段的ip并刷新client机器的resolv.conf配置，但是很多应用需要重启才能使用新的resolv.conf内的DNS IP，经常是1个机器上跑了各种agent，当前的负责人压根不了解是什么进程发起的。sysdig实际可以解决这样的case sysdig -p"%proc.name %proc.pid %fd.cip:%fd.cport %fd.sip:%fd.sport %fd.l4proto" fd.sport=“53” 另外有时也想看看ntp是否在做同步，可以用类似的方式 sysdig -p"%proc.name %proc.pid %fd.cip:%fd.cport %fd.sip:%fd.sport %fd.l4proto" fd.sport=“123” 附：1. sysdig介绍 http://www.sysdig.org/

默认情况下，连接sftp服务器(openssh内建的sftp server)时在服务器只能留下一个登陆连接的信息。为了便于知晓在一段时间内到底有哪些客户端来访问过本地的文件，可以通过调整sftp的日志。修改/etc/ssh/sshd_config，在sftp配置行添加”-l INFO” 完成配置```bash # override default of no subsystemsSubsystem sftp /usr/libexec/openssh/sftp-server -l INFO 

在使用salt做配置管理的时候，有时希望minion上能自动执行特定sls定义的动作，这个时候可以借助schedule来做。在pillar内定义好schedule的内容 schedule: dnsmaster: function: state.sls args: - dns.dnsmaster seconds: 10 pillar的top.sls里定义某个minion需要这个任务。 base: '*': - dns.alldns 'master1': - schedule 在minion上执行一次pillar数据的同步 salt-call saltutil.refresh_pillar

近期内部的递归服务器上有大量的AAAA查询，因为一些非主流NS的不响应AAAA记录，使得递归服务器上递归量比较大。bind9内开始支持filter-aaaa-v4/v6，主要的作用其实只是对相应的报文里作删除AAAA记录（如有）。单独验证了一下 filter-aaaa-on-v41.1 默认为no如果有AAAA记录会全量返回 AAAA记录如果没AAAA记录返回NOERR＋SOA1.2 设置为yes（Client IP为IPV4）如果有AAAA记录会被删除返回返回NOERR＋SOA如果没AAAA记录返回NOERR＋SOA1.3 设置为yes（Client IP为IPV6）行为不受影响。2. filter-aaaa-on-v62.1 默认为no如果有AAAA记录会全量返回 AAAA记录如果没AAAA记录返回NOERR＋SOA2.2 设置为yes（Client IP为IPV4）行为不受影响。2.3 设置为yes（Client IP为IPV6）如果有AAAA记录会被删除返回返回NOERR＋SOA如果没AAAA记录返回NOERR＋SOA filter-aaaa即便打开，当用户查询AAAA的时候bind也会去递归查询AAAA记录，所以并不能解决bind递归量大的问题。虽然可以通过iptables丢掉AAAA的包，但是也会影响用户的体验。

bind rpz和rrl作为bind 10里默认包含的2个模块，为bind的安全提供了有力的支撑。但实际使用不当会事得其反。 [ response-policy { zone zone_name [ policy (given | disabled | passthru | drop | nxdomain | nodata | cname domain) ] [ recursive-only yes_or_no ] [ max-policy-ttl number ] ; [...] } [ recursive-only yes_or_no ] [ max-policy-ttl number ] [ break-dnssec yes_or_no ] [ min-ns-dots number ] [ qname-wait-recurse yes_or_no ] ; ] 在服务器上配置如下的rpz策略 response-policy { zone “rpz.zone” policy given; } zone "rpz.zone" { type master; file "master/rpz.zone"; }; zone "lala.com" { type forward; forwarders { 8.8.8.8; }; }; rpz.zone内配置如下的内容，请求www.test.fr和*.lala.com都会阻塞很久，因为虽然我们做了策略，实际bind还是会等着取回结果再去操作。 $TTL 30 ...

参考网上找的资料，写了一个简单的脚本，输入域名可以生成使用iptables封禁dns请求的规则，使用于内部递归dns的一些基本防护。 #!/bin/bas h create_iptables(){ name=$1 string=$( echo $name|awk -F '.' '{for(i=1; i<=NF; i++){printf("|%02x|%s",length($i),$i)}}') string="$string|00|" echo -e "rule for \e[1; 32m $name \e[mquery:" echo "iptables -t raw -A PREROUTING -p udp --dport 53 -m string --hex-string "$string" --algo bm -j LOG --log-prefi x "drop an dns query "" echo "iptables -t raw -A PREROUTING -p udp --dport 53 -m string --hex-string "$string" --algo bm -j DROP" } create_iptables_ex(){ name=$1 declare -A types types["A"]="0001|" types["MX"]="000f|" types["CNAME"]="0005|" types["ANY"]="00ff|" types["AAAA"]="001c|" types["NS"]="0002|" types["SOA"]="0006|" for t in ${!types[@]} do ...

近两年tengine和nginx的在新特性的支持上差距越来越大。处于尝试新事物的好奇，动手升级到nginx-1.9.9。整个过程非常曲折，不再细说。。 主要的配置差异实际很小 listen 443 ssl so_keepalive=on spdy; 改为 listen 443 ssl so_keepalive=on http2; 但是因为之前开启了ssl_prefer_server_ciphers，升级前没仔细看过nginx官方的wiki，所以吃了不少苦头。升级之后页面直接就打不了， chrome 报错ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY。 Note that accepting HTTP/2 connections over TLS requires the “Application-Layer Protocol Negotiation” (ALPN) TLS extension support, which is available only since OpenSSL version 1.0.2. Using the “Next Protocol Negotiation” (NPN) TLS extension for this purpose (available since OpenSSL version 1.0.1) is not guaranteed. 搞定了http2后，另外奇葩的事情是blog打开就是空白的。php-fpm等运行正常，最终发现是nginx官方deb包里的fastcgi_params是错的，该用之前tengine使用的配置搞定。参考：1.http://nginx.org/en/docs/http/ngx_http_v2_module.html

近期内部开发反馈某些合作方的域名无法解析。团内同事分析发现这些域名都是托管在相同的一个域名厂商上,而且都是刷新cache后刚开始能解析，过段时间不能解析。 efly.cc bhc888.net 直接dig的时候返回信息如下 ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> efly.cc ; ; global options: +cmd ; ; Got answer: ; ; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7761 ; ; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;efly.cc. IN A ;; ANSWER SECTION: efly.cc. 600 IN A 121.9.13.185 ;; AUTHORITY SECTION: efly.cc. 168802 IN NS ns2.eflydns.net. efly.cc. 168802 IN NS ns1.eflydns.net. ...

Domain Name System Security Extensions (DNSSEC)DNS安全扩展，是由IETF提供的一系列DNS安全认证的机制,可参考RFC2535。DNSSEC主要是解决递归DNS到权威DNS直接的信任机制问题，并不能解决终端用户的任何问题。目前在国内企业中使用dnssec的比较少。究其原因有两点：1. 不配置也可以用。2. 配置了意义也不大。在国内绝大部分终端用户都是使用ISP分配的递归DNS，而这些递归dns还指望着对流量较大的域名做缓存加速以便节省网间结算费用，因此不会主动去支持DNSSEC。当这些递归DNS都不支持DNSSEC时，在权威DNS上实时DNSSEC的意义就很小了。DNSSEC本身实施起来不难，以我自己购买的1个域名gnuers.info为例.1. 域名注册在godaddy,支持添加DS记录。2. 域名服务器是自己在阿里云虚拟机上部署的bind，可以支持DNSSEC。当具备了这2个前提条件后，我就可以配置好域名服务器支持DNSSEC实施的步凑如下：1. 在本地生成密钥对 root# dnssec-keygen -a NSEC3RSASHA1 -b 4096 -n ZONE gnuers.info. root# dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE gnuers.info root#:/opt/bind/etc# ls *gnuers.info* Kgnuers.info.+007+15644.key Kgnuers.info.+007+15644.private Kgnuers.info.+007+38841.key Kgnuers.info.+007+38841.private 对zone做签名签名前需要先把公钥添加到zone文件内 $INCLUDE Kgnuers.info.+007+15644.key $INCLUDE Kgnuers.info.+007+38841.key 然后直接签名会生成一个新的zone文件,以.signed结尾。 dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N INCREMENT -o gnuers.info -t gnuers.info 配置named挑战zone文件为签名过的zone文件，并确认bind内开启dnssec支持。 dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; 在注册商添加ds记录签名zone文件的时候会同步生存ds文件：dsset-gnuers.info.，需要把里面的ds记录在godaddy上加上。 ...

内部有个产品本身是和mysql绑定在一起的。近期同步时出现”the table is full”。在网上搜了一下是一些参数设置问题，修改后重启mysql解决。```bash tmp_table_size = 2048Mmax_heap_table_size = 2048M