2292331981

只记录了几个关键步骤
tegnine-2.1.2 编译安装
编译选项:
–prefix=/usr/local/nginx –error-log-path=/data/nginx/logs/error.log –pid-path=/usr/local/nginx/nginx.pid –http-log-path=/data/nginx/logs/access.log –user=nginx –group=nginx –with-http_upstream_check_module –with-http_stub_status_module –with-http_ssl_module –with-http_upstream_consistent_hash_module –with-http_v2_module –with-http_spdy_module –with-http_gunzip_module –with-debug –with-http_lua_module –with-luajit-lib=/usr/local/lib/ –with-openssl=/usr/src/install/openssl-1.0.2j/ –with-openssl-opt=enable-tlsext –with-pcre –with-http_dyups_lua_api –add-module=/usr/src/install/ngx_devel_kit-master/ –add-module=/usr/src/install/ngx_cache_purge/ –add-module=/usr/src/install/nginx-goodies-nginx-sticky-module-ng-08a395c66e42/ –with-cc-opt=’-O2 -DTCP_FASTOPEN=23 -DNDK’

编译安装完成后打成rpm包
fpm -s dir -t rpm –name at_tengine –version 2.1.2 –iteration 9 –architecture x86_64 –vendor “ATHM” -C /data/rpmbuild/compile_dir/tengine4/ -p /data/rpmbuild/rpms/ –description ‘My auto tengine’ –url ‘/blog.itopss.com’ –maintainer “wnfmq@126.com” –category “Application” –post-install /data/rpmbuild/compile_dir/tengine4/usr/local/nginx/bin/install_after.sh –pre-uninstall /data/rpmbuild/compile_dir/tengine4/usr/local/nginx/bin/remove_after.sh -d “openssl,zlib”

安装初始化:
http模块添加一行:
proxy_cache_path /dev/shm/cache1 levels=1:2 keys_zone=static1:10m inactive=2h max_size=4g;

server里面添加:
location / {
proxy_pass /reply_itopss_com;
proxy_cache static1;
proxy_cache_valid 200 1h;
proxy_cache_valid 302 10m;
proxy_cache_valid any 1m;
add_header X-Via $server_addr;
add_header X-Cache-Status $upstream_cache_status;

}

缓存清理的api接口
location ~ /purge(/.*) {
allow 127.0.0.1;
allow 10.168.0.0/16;
deny all;
proxy_cache_purge static1 $1$is_args$args;
}

访问链接:
/domainname/cache_web/expire?a=0
清理缓存命令:
curl ‘/domainname/purge/cache_web/expire?a=0’

salt 执行一条命令返回俩次结果问题处理

使用salt执行命令,有时会返回俩次结果,这个是为什么呢?
salt-2

登录minion查看日志:
salt-3
可一看到 salt-minion retry 了,为什么要重新验证呢?,很可能是验证失败了,查看minion的配置文件。
salt-4
我们看到salt-minion的验证超时时间只有5s钟,我们改大一些设置成30s。
重启salt-minion
/etc/init.d/salt-minion restart
master 端来验证发现还是有问题
再次查看saltminin端汇报:
salt-5
发现是同一个 jid,意思说saltmaster端只发了一次,我却俩次匹配到了。发生这样的事情是因为我的双master配置,俩个master因为在hosts里面写的入口公网ip地址不同,但是都映射到了一台设备。所以这台master每次执行都会返回俩次结果。另一台master到minion不通信。

7789546526

昨天遇到个salt问题,大批的设备连接中断,查找到设备的网络,key,以及连通性检查,都没有问题。查看saltmaster日志,大量的设备重连。看message消息,有这样的记录: kernel: possible SYN flooding on port 4506. Sending cookies.

查看链接记录:

netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
TIME_WAIT 277
CLOSE_WAIT 1
FIN_WAIT1 35
ESTABLISHED 1823
SYN_RECV 165

我的设备有3k台左右,有一半的设备已经不通信,全部是内网环境,应该不会有4506的syn攻击的,因为流量很大,其它业务线的战友急用salt进行任务发布,没有细查问题,直接重启master,大约10分钟后minion恢复链接。

再查问题原因,进行抓包,大约抓了2分钟

tcpdump -i eth0 port 4506 -w /tmp/abc.dmp -vv

读取抓取的包到文件,因为tcpdump 读取文件的时候反应比较慢,直接写文件了。

tcpdump -r /tmp/abc.dmp > /tmp/abc.txt

 

grep ‘Flags \[S.\]’ /tmp/abc.txt |awk -F: ‘{print $3}’|awk ‘{print $NF}’|awk -F. ‘{print $1″.”$2″.”$3″.”$4}’ | sort | uniq -c |awk ‘$1>20{print $0}’
21 xx.xx.40.9
47 xx.xx.240.41
47 xx.xx.240.8
50 xx.xx.240.9

查找那些 设备syn链接数量 太多,有4台设备明显的有问题,进行网络排查,发现telnet saltmaster 的4506 端口不通信、 答案就找到了。你找到了吗?

windows puppet调用wmic设置path问题

最近踩到了一个很深puppet的坑,跌的挺疼,写此blog以做留念,也给玩puppet的人一点提示

事故发生原因:

部门内部发现很多windows设备cmd.exe 快捷方式点击不开,右击我的电脑->属性->环境变量,提示 %windir%变量不存在。刚刚开始只发现了几台,慢慢设备数量一天比一天多,大家都意识到这个可能是配管导致的(因为只有配管会管理所有的设备)我反应慢了,一个是我第一次批量管理windows,之前都是在linux环境下面干活,不知道windows下的水有多深,一直在淌着过河,另一个是我知道%windir%这个全局变量我的puppet 配管根本就没有管理过,怎么会是我搞没有了呢,我全局都查了一遍,包括所有的文本文件,还是大意了。里面最大奇异的是wmic 更新path环境变量,查了近5天没有找到怎么就搞坏了。

如下是有歧义的puppet文件

exec { “set_environment”:
cwd => “c:/xxx”,
command => ‘cmd.exe /c c:/xxx/environment.bat’,
group => ‘Administrators’,
path => $::path,
refreshonly => true,
subscribe => File[“environment”],
}

这个是执行的命令:    wmic ENVIRONMENT where “name=’PATH’ and username='<system>'” set VariableValue=”%path%;C:\Program Files\Puppet Labs\Puppet\bin;C:\Program Files\Puppet Labs\Puppet\sys\ruby\bin”

另一套歧义的配置

exec {‘set-path.bat’:
cwd => ‘c:\package_dir’,
command => “cmd.exe /c set-path.bat”,
path => $::path,
}

文件set-path.bat的内容:

wmic ENVIRONMENT where “name=’PATH’ and username='<system>'” set VariableValue=”%path%;C:\Python27;C:\Python27\Lib\site-packages\pywin32_system32;C:\salt\bin\Lib\site-packages\pywin32_system32″

崩溃时的 %path% C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Puppet Labs\Puppet\bin;C:\Program Files (x86)\Puppet Labs\Puppet\sys\ruby\bin;C:\Program Files (x86)\Puppet Labs\Puppet\bin;C:\Program Files (x86)\Puppet Labs\Puppet\sys\ruby\bin;C:\Program Files (x86)\Puppet Labs\Puppet\bin;C:\Program Files (x86)\Puppet Labs\Puppet\sys\ruby\bin;C:\Program Files (x86)\Puppet Labs\Puppet\bin;C:\Program Files (x86)\Puppet Labs\Puppet\sys\ruby\bin;D:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;D:\Program Files\Microsoft SQL Server\100\Tools\Binn\;D:\Program Files\Microsoft SQL Server\100\DTS\Binn\;D:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\;D:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\;C:\Program Files (x86)\Puppet Labs\Puppet\puppet\bin;C:\Program Files (x86)\Puppet Labs\Puppet\facter\bin;C:\Program Files (x86)\Puppet Labs\Puppet\hiera\bin;C:\Program Files (x86)\Puppet Labs\Puppet\sys\tools\bin;C:\Program Files (x86)\Puppet Labs\Puppet\puppet\bin;C:\Program Files (x86)\Puppet Labs\Puppet\facter\bin;C:\Program Files (x86)\Puppet Labs\Puppet\hiera\bin;C:\Program Files (x86)\Puppet Labs\Puppet\sys\tools\bin;C:\Program Files (x86)\Puppet Labs\Puppet\puppet\bin;C:\Program Files (x86)\Puppet Labs\Puppet\facter\bin;C:\Program Files (x86)\Puppet Labs\Puppet\hiera\bin;C:\Program Files (x86)\Puppet Labs\Puppet\sys\tools\bin;C:\Program Files (x86)\Puppet Labs\Puppet\puppet\bin;C:\Program Files (x86)\Puppet Labs\Puppet\facter\bin;C:\Program Files (x86)\Puppet Labs\Puppet\hiera\bin;C:\Program Files (x86)\Puppet Labs\Puppet\sys\tools\bin;C:\Program Files (x86)\Puppet Labs\Puppet\puppet\bin;C:\Program Files (x86)\Puppet Labs\Puppet\facter\bin;C:\Program Files (x86)\Puppet Labs\Puppet\hiera\bin;C:\Program Files (x86)\Puppet Labs\Puppet\sys\tools\bin;C:\Program Files (x86)\Puppet Labs\Puppet\puppet\bin;C:\Program Files (x86)\Puppet Labs\Puppet\facter\bin;C:\Program Files (x86)\Puppet Labs\Puppet\hiera\bin;C:\Program Files (x86)\Puppet Labs\Puppet\sys\tools\bin;C:\Program Files (x86)\Puppet Labs\Puppet\puppet\bin;C:\Program Files (x86)\Puppet Labs\Puppet\facter\bin;C:\Program Files (x86)\Puppet Labs\Puppet\hiera\bin;C:\Program Files (x86)\Puppet Labs\Puppet\sys\tools\bin;C:\Program Files (x86)\Puppet Labs\Puppet\puppet\bin;C:\Program Files (x86)\Puppet Labs\Puppet\facter\bin;C:\Program Files (x86)\Puppet Labs\Puppet\hiera\bin;C:\Program Files (x86)\Puppet Labs\Puppet\sys\tools\bin;C:\Python27;C:\Python27\Lib\site-packages\pywin32_system32;C:\Python27;C:\Python27\Lib\site-packages\pywin32_system32;C:\Python27;C:\Python27\Lib\site-packages\pywin32_system32;C:\Python27;C:\Python27\Lib\site-packages\pywin32_system32;C:\Python27;C:\Python27\Lib\site-packages\pywin32_system32;C:\Python27;C:\Python27\Lib\site-packages\pywin32_system32;C:\Python27;C:\Python27\Lib\site-packages\pywin32_system32;C:\Python27;C:\Python27\Lib\site-packages\pywin32_system32;C:\salt\bin\lib\site-packages\pywin32_system32;

后面这套配置确实有问题,puppet 每重启一次,环境变量多追加后面这部分内容,这个怎么就造成windir的变量丢失了呢? 原来环境变量的大小是有字节数量限制的,默认是4k。puppet多次反复的追加,导致path环境变量超过了这个大小。而导致系统内部环境变量异常。cmd等等一些快捷方式直接崩溃。

故事讲到这里貌似找到了问题的答案,可是前面的重复部分是从哪儿来的呢,我又把我的puppet所有的配置全部扒拉了一遍,没有找到关于这部分的配置,从哪儿出来的呢?也是扒拉puppet的启动脚本,我了个去:

SET PUPPET_DIR=%PL_BASEDIR%\puppet
SET FACTER_DIR=%PL_BASEDIR%\facter
SET HIERA_DIR=%PL_BASEDIR%\hiera

SET PATH=%PUPPET_DIR%\bin;%FACTER_DIR%\bin;%HIERA_DIR%\bin;%PL_BASEDIR%\bin;%PL_BASEDIR%\sys\ruby\bin;%PL_BASEDIR%\sys\tools\bin;%PATH%

这一下就又找到问题了,每次puppet重启的时候都不会去判断当前的%path%有没有自己的模块目录,都会在系统%path%环境变量前面增加自己的变量,造成当前%path%变量有很多重复,在wmic调用命令追加变量的时候顺利的带到%path%里面去了,这个也成了很快到瓶颈的最大的帮凶。

问题似乎是完美发现了,还有另一个坑在等着呢,在经过大量的测试后,如果有俩个模块同时需要修改path环境变量,puppet重启的话,只有最后一个改的生效。是不是雷还蛮多的,你踩到了吗?