在写check_if_flow.sh的时候，因为要比较的值太多，几个网卡，每个都分进出、然后分w和c。如果直接if判断大小，会写的无比庞大……于是想到根据比较结果先输出一个变量，大就是1，小就是0，类似这种。 继续阅读……

流量监控，一般看cacti上的绘图。近日打算设置报警，懒得给cacti加模块，自己写个脚本吧，于是开始研究这个流量监控的方式。 先是在网上看到一个nagios的check_traffic.sh脚本，核心就是用snmpwalk取网卡总流量，写在/tmp/某个文件下，下次nrpe启动check时，再去新的总流量，减去文件中读取出来的值，除以启动间隔时间，就是平均流量值。 用snmpwalk -v 2c -c public localhost IF-MIB::ifInOctets取出值来一看，发现和ifconifg出来的RX数值是一样的！ 然后有张宴的net.sh脚本，从/proc/net/dev中取值，然后存进变量后，sleep一定时间，再取一次，同样相减再做除法，得出平均流量值。 再cat /proc/net/dev和ifconfig的一比较，数值也是一样的，把两个脚本设定相同间隔，同时运行，显示的结果都是一样的！ 那从本机监控的角度来说，那当然是从proc中取值计算容易了。毕竟给一大把机器装snmpwalk很费的…… （因为近期cacti上的图时不时有某些机器突发满载流量尖峰，持续时间又很短，所以靠cacti或者nagios本身这种间隔性轮询扫描很可能就错过去了） 最终想法是，在机器上后台长期运行监控脚本，碰到流量突发，发送到监控服务器，监控服务器上开启sniffer或者wireshark抓包，同时发邮件报警。 目前初步完成监控客户端脚本如下： 继续阅读……

今天逛到淘宝核心系统组的公开博客，然后知道了淘宝开源平台http://code.taobao.org/，刚出来的东东，上面开源了淘宝目前正在使用的key-value分布式存储tair和nginx的concet模块、Cookie模块，以及这个平台本身的代码……在回复中，淘宝的人说有关tair的update都会同步在这个平台上进行，而不是另起一个闭源分支，或者想新浪的sina-sdd那样放弃。据说九月份，淘宝还会放出它的分布式文件系统TFS来，毕竟时间不长，会不会“人亡政息”，有待考验…… 继续阅读……

话接上篇。 在发现经过squid的刷新请求头不带If-None-Match后，向squid-user发邮件询问。Amos回复如下： 继续阅读……

手上有一个伪静态的论坛bbs.example.com，每当有用户回复帖子的时候，提交到r.bbs.example.com，然后由r.bbs.example.com的提示页面replyautojump.jsp延迟3000后调用window.location.href函数返回原来的帖子——期间即完成对该帖的静态化。 继续阅读……

nagios自带的check_antp太过简约，除了状态统计输出外，什么参数都不提供。在面对不同应用服务器时，报警就成了很大问题。于是决定自己写一个check脚本。作脚本运行，与命令操作时一个不同，就是要考虑一下效率问题。在高并发的机器上定期运行netstat -ant命令去统计，显然不太合适，可以直接从proc系统中取数据，这就快多了。 继续阅读……

一般来说流量带宽是通过snmp协议取网卡流量画图。不过有的时候，为了优化分析或者排错，也会直接去计算服务的访问流量。方法很简单，根据日志中记录的请求时间（squid记录的是请求响应完成时间，如果要精确，可以再减去响应时间，不过一般squid的文件不至于5分钟内还传不完的……），按每5分钟一汇总其字节数，然后均摊到300秒上。 继续阅读……

网站某频道准备启用新域名，切换过程中，为了保证网民访问效果，对老域名下的所有请求设置了重定向到新域名下相同url。测试访问正常后上线使用。 继续阅读……

对专门的存储设备实在所知甚少，今天有时间找了找netapp的资料看看，有点基本了解。资料见豆丁：http://www.docin.com/p-56454923.html 继续阅读……

之前用ports把BSD系统的login-shell改成bash后，今天又打算改回csh去。不料重新chsh -s /bin/csh后，却弹出如下错误提示： 继续阅读……

新迁移一例apache+resin系统，运行不久后时不时就出现500错误。从日志中看到如下报错： 继续阅读……

公司网站一部分动态页面，早先使用apache+resin的架构运行，考虑到高并发访问下的响应性能问题，在前不久逐步开始用nginx替换掉了apache。
不过随后发现了一个问题，随意进入某一有分页的网页，第一页是正常的（因为静态化过了）；点“下一页”，出来的页面两边正常，中间部分的标题、关键字等也正常，唯独每个标题下的正文无法正常显示。
因为有做过系统调整，所以第一反应就是新上的nginx配置有问题。按照经验，可能是nginx.conf中指定的chaset与borwser不一致？但选定utf8后现象依旧，何苦同一页面内的其他字符又是正确显示的~~~
然后通过内网IP+端口的方式，直接向resin请求抓取到的乱码页面url。结果，nginx+resin的机器显示乱码，apache+resin的机器显示中文——由此确认问题不是nginx，而是resin的！
diff两台机器的resin.conf，除了开启的端口外，没有任何不同的地方。
检查两台机器的环境变量，发现nginx这台的LANG是zh_CDN:gbk（静态化程序有需求），而apache这台是utf8。试着也修改成utf8然后重启resin，访问结果依然不对。
这下基本没招了……完全一样的环境和配置，取的同一台nfs的数据，为啥就能显示不同呢？难道是编译参数的问题？
去sharepoint上下载公司文档，查看原先的resin都使用了那些configure选项。结果发现为了配合apache，使用了–with-apache等。莫非就是因为这个原因导致resin脱离apache运行出现问题了？
下载和现行resin版本一致的源码报，不再with-apache编译完成，cp一份conf过来，改用另一个端口启动，然后通过这个端口访问那个url，结果显示正常了！
替换下原先的resin，把nginx的upstream指向新resin，故障解决。
看来以后再替换apache+resin成nginx+resin的时候，resin也要重新编译一个了…… 继续阅读……

$RANDOM是linux自带的一个随机数变量，其随机范围从0-32767（man bash说的）。每次unset再恢复后，$RANDOM都会变化。 继续阅读……

在对squid进行目录刷新的时候，一般使用的脚本都是采用for i in squidclient mgr:objects|grep $1|awk '{print $2}';do squidclient -m purge “$i”;done的方式。 继续阅读……

从网上看到的两个锁定，都是util-linux包里的。 继续阅读……

闲来无事，打算自己安装一个xen虚拟机，看了看文档，知道必须采用网络安装方式（NFS/FTP/HTTP），于是随手去搜狐镜像站下了一个iso下来挂载用。 不过virt-install一直报错。 首先是： mount.nfs: Input/output error umount: /var/lib/xen/xennfs.jfkgaj: not mounted ERROR:  Unable to mount NFS location! 诡异了，我手动都能mount上远端的nfs了~~百度没结果，谷大婶出动，原来这边也要启动portmap才行。 下一步，继续出错： ERROR:  Invalid NFS location given: [Errno 2] No such file or directory: ‘/var/lib/xen/xennfs.JjVbzO/images/xen/vmlinuz’ 没有文件？返回nfs上去看，嗯，目录下只有一个LiveCD，一个isolinux。咋回事呢？ 又返回搜狐去翻目录，在os/下看到了images/xen/vmlinuz，难道要把整个os/目录下载了？可我记得这个目录就应该是iso挂载后的东西呀~ 返回isos/去看，终于发现一个极弱智的问题：目录下有LiveCD和bin-DVD两个镜像，我直接点了最顶上的一个，也就是LiveCD那个…… 赶紧重新下载…… 之后一路顺利。 A机(10.10.10.10)上： 继续阅读……

今天继续查找mod_perl对req_header的处理。 继续阅读……

客户的要求，还剩下最后一步，就是referer限定。对于apache，有Mod_rewrite现成的可用： 继续阅读……

今天有客户传过来一张报障截图，乍一看很正常的拒绝访问而已。可仔细一看，吓，地址栏里的url和errorpage返回的%U居然不一样！！ 浏览器中写的是域名，squid却按配置拒绝的是对服务器ip发起的直接请求。 赶紧去日志服务器上汇总deny信息，终于找到了相关日志。都是一个ip发过来的，大概如下： 2010-05-25-14:04:13 0 60.209.232.219 TCP_MEM_HIT/200 15555 GET http://jobseeker.zhaopin.com/zhaopin/aboutus/law.html - NONE/- text/html “-“ “-“ 2010-05-25-14:05:19 2 60.209.232.219 TCP_DENIED/403 1464 GET http://113.6.255.97/zhaopin/aboutus/law.html - NONE/- text/html “-“ “-“ 2010-05-25-14:06:01 1 60.209.232.219 TCP_DENIED/403 1464 GET http://113.6.255.97/zhaopin/aboutus/law.html - NONE/- text/html “-“ “-“ 2010-05-25-14:10:00 1 60.209.232.219 TCP_DENIED/403 1464 GET http://113.6.255.97/zhaopin/aboutus/law.html - NONE/- text/html “-“ “-“ 2010-05-25-14:10:00 0 60.209.232.219 TCP_MEM_HIT/200 679 GET http://jobseeker.zhaopin.com/favicon.ico - NONE/- application/octet-stream “-“ “Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)” 2010-05-25-14:12:39 2 60.209.232.219 TCP_DENIED/403 1464 GET http://113.6.255.97/zhaopin/aboutus/law.html - NONE/- text/html “-“ “-“ 2010-05-25-14:12:41 1 60.209.232.219 TCP_DENIED/403 1464 GET http://113.6.255.97/zhaopin/aboutus/law.html - NONE/- text/html “http://jobseeker.zhaopin.com/zhaopin/aboutus/law.html” “Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)” 截图的那个时间点，日志中的user-agent居然是空！而且就在短短的一分钟前后，就连续出现正确和错误的反复访问。。。。。。在同事的提醒下，试着扫描了一下这个clientip，发现它还开着80端口： 继续阅读……

上回提到的防盗链方式是在strings上加上key和time，uri本身是不变的，这种方式其实现在不是很主流，主流的方式是将计算得出的加密串直接改在uri的路径里。比如下面将要提到的例子。要求其实和早先那个squid防盗链的一模一样，就是改成用apache来跑。 继续阅读……

还是那本《linux操作系统之奥秘》，系统管理性能调校章节。7.1.3 Jumbo Frame： 继续阅读……

几个跟ctrl有关的操作，很有爱，贴一下： 继续阅读……

在http://www.fayland.org/journal上看到一张图，感觉很舒服很明白，转帖过来。 继续阅读……

在对HTTPS进行反向代理的时候，如果源站未能提供SSL的cert和key，可以采用TCP协议的端口转发完成。最常见的是iptables，还有rinetd。之前的博文中都有提到。
今天碰到一个事情，使用rinetd进行443转发的客户，全网都无法访问了……
proxy上对源站443端口能telnet通，绑定ie访问源站是没有问题；proxy的443端口本地也能telnet通，但是ie访问就是打不开任何页面。
偶然想起strace，觉得对rinetd进程进行跟踪试试。strace -p 13916，然后这边打开ie，输入https的域名，回车……
看到服务器tty上显示如下信息：
select(16, [4], [], NULL, NULL)         = 1 (in [4])
#rinetd程序处于select()，运行的FD为4
accept(4, {sa_family=AF_INET, sin_port=htons(3766), sin_addr=inet_addr(“211.99.216.18”)}, [16]) = 6
#从我本机的3766端口发起请求，被服务器接受，FD为6
ioctl(6, FIONBIO, [1])                  = 0
#设定该socket为阻塞状态
setsockopt(6, SOL_SOCKET, SO_LINGER, [0], 4) = -1 EINVAL (Invalid argument)
#设定其为异步处理方式，不错失败了……汗
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
#打开FD为7的socket，tcp传输方式为stream流方式
bind(7, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(“0.0.0.0”)}, 16) = 0
#服务器打开对任一端口的监听
setsockopt(7, SOL_SOCKET, SO_LINGER, [0], 4) = -1 EINVAL (Invalid argument)
ioctl(7, FIONBIO, [1])                  = 0
#设定这个向源请求的socket为已阻塞
connect(7, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr(“222.73.34.25”)}, 16) = -1 EINPROGRESS (Operation now in progress)
#向222.73.34.25的443端口发送请求
select(16, [4 6 7], [], NULL, NULL)     = 1 (in [6])
recvfrom(6, “2631A1=31K36536423”217:352346225207N7qP’342!2008”…, 1024, 0, NULL, NULL) = 70
#从FD6即连接客户电脑的socket收到的内容
select(16, [4 6 7], [7], NULL, NULL)    = 2 (in [7], out [7])
recvfrom(7, 0x111e6860, 1024, 0, 0, 0)  = -1 EHOSTUNREACH (No route to host)
#从FD7即回源的socket收到的内容——“无法找到连接主机的路由”！！
close(7)                                = 0
#关闭FD7
select(16, [4 6], [6], NULL, NULL)      = 1 (out [6])
time(NULL)                              = 1274410006
stat(“/etc/localtime”, {st_mode=S_IFREG|0644, st_size=405, …}) = 0
close(6)                                = 0
#关闭FD6，这个是我关闭ie后关闭的。
很奇怪呀，这个222.73.34.25是什么地址？ping客户域名返回的明明不是这个ip呀？
试着kill rinetd，然后重启动rinetd服务。再重复如上操作。相关内容如下：
accept(4, {sa_family=AF_INET, sin_port=htons(3917), sin_addr=inet_addr(“211.99.216.18”)}, [16]) = 6
ioctl(6, FIONBIO, [1])                  = 0
setsockopt(6, SOL_SOCKET, SO_LINGER, [0], 4) = -1 EINVAL (Invalid argument)
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
bind(7, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(“0.0.0.0”)}, 16) = 0
setsockopt(7, SOL_SOCKET, SO_LINGER, [0], 4) = -1 EINVAL (Invalid argument)
ioctl(7, FIONBIO, [1])                  = 0
connect(7, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr(“219.235.4.17”)}, 16) = -1 EINPROGRESS (Operation now in progress)
#回源地址是219.235.4.17，这个正是ping出来的正确源ip！
select(18, [4 6 7], [], NULL, NULL)     = 1 (in [6])
recvfrom(6, “2631A1=31K365365f334370210367202260B33332E3337232423340s21”…, 1024, 0, NULL, NULL) = 70
select(18, [4 6 7], [7], NULL, NULL)    = 1 (out [7])
sendto(7, “2631A1=31K365365f334370210367202260B33332E3337232423340s21”…, 70, 0, NULL, 0) = 70
select(18, [4 6 7], [], NULL, NULL)     = 1 (in [7])
recvfrom(7, “2631r2432F31K365365U10200u236332*Mf316l2252306v254350364”…, 1024, 0, NULL, NULL) = 1024
select(18, [4 6], [6], NULL, NULL)      = 1 (out [6])
……
#这些recv和send就是页面请求的传输过程，ie上显示出来正确的页面了。 返回去查找之前的工单，也确认了222.73.34.25正是该客户之前的源站ip，而后改成219.235.4.17的。 由此看来rinetd虽然可以在conf里写域名，但其对域名的解析，只会在启动的时候执行一次，之后就一直持续对固定的那个ip进行转发了！ 继续阅读……

一直以为squid的url_rewrite就是改写url后，传给squid分析是否缓存，然后返回缓存或者回源。在浏览器地址栏上的url是不变的。 今天才知道在print $uri的时候，可以给他加上http_code。变成print 302:$uri的格式，然后就可以由浏览器发起302跳转到新页面了。 继续阅读……