为IT服务 [龙飞的博客]

环境是win2003 iis6 php(isapi)
应用是个dz，最近在上了cdn后发现用户过来的ip都是squid服务器的地址，看了下dz的源代码

1
2
3
4
5
6
7
8
9

if(getenv('HTTP_CLIENT_IP') && strcasecmp(getenv('HTTP_CLIENT_IP'), 'unknown')) {
	$onlineip = getenv('HTTP_CLIENT_IP');
} elseif(getenv('HTTP_X_FORWARDED_FOR') && strcasecmp(getenv('HTTP_X_FORWARDED_FOR'), 'unknown')) {
	$onlineip = getenv('HTTP_X_FORWARDED_FOR');
} elseif(getenv('REMOTE_ADDR') && strcasecmp(getenv('REMOTE_ADDR'), 'unknown')) {
	$onlineip = getenv('REMOTE_ADDR');
} elseif(isset($_SERVER['REMOTE_ADDR']) && $_SERVER['REMOTE_ADDR'] && strcasecmp($_SERVER['REMOTE_ADDR'], 'unknown')) {
	$onlineip = $_SERVER['REMOTE_ADDR'];
}

对比了下另外一台linux的机器发现是可以取到的。
于是用_SERVER["HTTP_X_FORWARDED_FOR"]试了试是可以取到用户ip的，难道在windows下面不能用getenv？
最后略微修改了下dz的代码搞定了

1
2
3
4
5
6
7
8
9
10
11

if(getenv('HTTP_CLIENT_IP') && strcasecmp(getenv('HTTP_CLIENT_IP'), 'unknown')) {
	$onlineip = getenv('HTTP_CLIENT_IP');
} elseif(getenv('HTTP_X_FORWARDED_FOR') && strcasecmp(getenv('HTTP_X_FORWARDED_FOR'), 'unknown')) {
	$onlineip = getenv('HTTP_X_FORWARDED_FOR');
} elseif($_SERVER["HTTP_X_FORWARDED_FOR"] && strcasecmp($_SERVER["HTTP_X_FORWARDED_FOR"], 'unknown')) {
	$onlineip = $_SERVER["HTTP_X_FORWARDED_FOR"];
} elseif(getenv('REMOTE_ADDR') && strcasecmp(getenv('REMOTE_ADDR'), 'unknown')) {
	$onlineip = getenv('REMOTE_ADDR');
} elseif(isset($_SERVER['REMOTE_ADDR']) && $_SERVER['REMOTE_ADDR'] && strcasecmp($_SERVER['REMOTE_ADDR'], 'unknown')) {
	$onlineip = $_SERVER['REMOTE_ADDR'];
}

其实半个多月前就体验过EVDO了，同事去采访发布会的时候带回来过一个，那次纯粹就是安装上网流程化体验了下，记得是个华为的设备。

这次单位领导正好把以前的老的cmda上网卡去换了个回来，由于老婆童装店里也正在考虑搞个无线上网省的装宽带了，所以带回来试了试信号顺便试用下。

这次的拿回来的2个是中兴 AC560的设备，东西蛮好看就个u盘大小，上面除了uim卡插槽外还有个tf卡插槽，能当读卡器用，貌似还有2喇叭。做工不错

由于有了上次安装的经验，所以直接就像u盘那样插进usb口，电脑提示发现新硬件，其实是个u盘，里面就是上网卡的驱动，现在这设计蛮好的省的光盘了。一路驱动装完后出现了拨号界面，直接选3G，顺利上网，连接速率3.1M。

选择本地服务器测试了下载和上传速度，用的ftp单线程，下载峰值200kb出头，平均在100kb上下，上传峰值80多kb，平均在50kb上线。上传和下载基本处于上下波动状态忽高忽低，没有一刻是稳定的。下载的同时上传会对下载速度有一些影响。

浏览网页，qq等操作那是和adsl基本无异，速度飞快，比以前1x快不知道多少倍。

试用感觉良好，连接目前看来很稳定，可以考虑作为宽带替代方案，就是不知道费用如何。

#首先全部允许数据包通过，防止默认丢包的话下面删除规则造成数据包全部丢掉
#允许所有进来的包
iptables -P INPUT ACCEPT
#允许所有出去的包
iptables -P OUTPUT ACCEPT

#初始化iptables 清空所有规则和组
#删除所有规则
iptables -F
#删除所有组
iptables -X

#这里才是正式开始配置iptables
#创建新的定义firewall_in
iptables -N firewall_in

#指定firewall_in组应用到INPUT chain，类似于应用组
iptables -A INPUT -j firewall_in

#指定firewall_in组应用到FORWARD chain，类似于应用组。
iptables -A FORWARD -j firewall_in

#这里开始增加规则，这里例子里规则都是添加到firewall_in组
#localhost数据包全部允许通过
iptables -A firewall_in -i lo -j ACCEPT

#所有已经建立连接的数据包全部通过
iptables -A firewall_in -m state –state RELATED,ESTABLISHED -j ACCEPT

#所有地址开放tcp 80端口
iptables -A firewall_in -p tcp -m tcp –dport 80 -j ACCEPT

#ping数据包允许每秒通过1个
iptables -A firewall_in -p icmp -m limit –limit 1/s –limit-burst 10 -j ACCEPT

#向10.1.1.0/255.255.255.0网段开放eth0网卡上面并且目的ip地址为10.1.1.1的22端口（这是一个功能示例：网卡、协议类型、源地址组、目的地址、目的端口都有体现）
iptables -A firewall_in -i eth0 -p tcp -m tcp -s 10.1.1.0/255.255.255.0 -d 10.1.1.1 –dport 22 -j ACCEPT

#下面这2行是ftp server的pasv模式开放示例，因为ftp的pasv模式端口是随机打开的所以需要另外设置ftp server的pasv端口范围为60000-60004
iptables -A firewall_in -p tcp -m tcp -s 10.1.1.2 –dport 21 -j ACCEPT
iptables -A firewall_in -p tcp -m tcp -s 10.1.1.2 –dport 60000:60004 -j ACCEPT

#丢弃不符合规则的其它tcp和udp数据包，如果处于调试的最好先不要用这2行，万一规则错了就麻烦了
iptables -A firewall_in -p tcp -m tcp -j DROP
iptables -A firewall_in -p udp -m udp -j DROP

#清除规则匹配数据包计数信息
iptables -Z

#禁止所有进来的包，iptables是从上往下匹配的，如果有符合的话就结束匹配了，这里丢弃和上面规则里面的丢弃相比更加彻底。
#同样如果处于调试的最好先不要用这2行，万一规则错了就麻烦了
iptables -P INPUT DROP

#应许所有出去的包，这个防火墙只是简单的进行入站包的过滤，如果需要出站包也要过滤话可以给OUTPUT chain单独一个组然后把参考上面把出站规则写到对应的组里
iptables -P OUTPUT ACCEPT

#最后保存iptables，这样重启后也能应用
/etc/init.d/iptables save

虽然iptables可以通过命令进行修改插入和删除操作，但是这里极不推荐新手这样来修改iptables，我推荐大家是把我上面的这样的命令(去掉注释)保存下来，一方面是做好记录，另一方面在下次修改的时候可以很方便的修改文本，然后把命令全部粘贴进命令行就行。

另外查看目前iptables的内容指令：
iptables -L -vn

Update Manager是一款VMware VirtualCenter插件，可以对esx和vm操作系统 进行在线补丁更新。

前两天看到esx已经出3.5 u4了，所以今天抽空打算升级一下的，启用Update Manager，设置更新内容下载补丁都蛮正常，结果在对esx主机进行 scan for updates（扫描更新） 的时候出错。事件里面提示patch metadata for xxxx missing. please download updates metadata first.

去官网kb补习了一下，说这种情况一般是esx无法连上vc的um造成的。常见的可能性就是：
1是esx的防火墙没开8080的out规则
2是vc的机器上可能有多个ip或者网卡，恰好um给esx的ip或者vc的hostname esx连接不上。

所以解决方法首先就是打开esx 防火墙的访问外部8080端口
用ssh登入上esx（注意root用户默认是无法ssh登陆的）先su到root权限执行下面指令：
/usr/sbin/esxcfg-firewall -o 8080,tcp,out,updatemanager

如果安装vc的时候选择的http端口不是8080请做相应修改。

然后在vc主机上在服务里停掉VMware Update Manager Service，在进入Update Manager目录修改文件：
C:\Program Files\VMware\Infrastructure\Update Manager\vci-integrity.xml

找到
<HostConfig>
下面的
<PatchDepotUrl/>
改为
<PatchDepotUrl>http://192.168.0.1:8080/vci/hostupdates/hostupdate</PatchDepotUrl>

其中192.168.0.1就是esx能ping通并且访问到的vc的ip地址，8080端口为安装vc的时候选择的http端口。

然后再启动VMware Update Manager Service，这时应该需要在vc里面重新启用下Update Manager。然后再对esx主机进行扫描更新就可以通过了。

官方对于这个问题的kb：

http://kb.vmware.com/kb/1004914

http://kb.vmware.com/kb/1004330

以前写过个4.0的，现在机器上都是5.0的了，也不知道兼容不兼容4.0的参数，所以干脆看着help重新写了个

我这的环境都是gbk所以下面是以gbk为例子
导出：

1

mysqldump --user="xxx" --password="xxx" --force --quick --skip-opt --create-options --add-drop-table --default-character-set=gbk db1 >db1.sql

其中–force 代表忽略错误，如果导出的数据要导入mysql 4.0的话加个参数–compatible=mysql40

导入：

1

mysql -u"xxx" -p"xxx" --default-character-set=gbk db1 <db1.sql

就我这台跑博客的机器，nginx-0.7.37 + php 5.2.8(fastcgi)出现个极度诡异的现象，就是无论php.ini怎么设置display_errors，永远无错误信息显示，觉得不是我搞错文件或者其它问题，别的配置都有效，就是display_errors 设置为on 进phpinfo一看还是off，昏倒，怎么最近老是碰到问题撒，只能log到文件看出错信息。同样的环境在另外一台机器确实好的
最后检查来检查去发现php-fpm.conf里面还有个关于display_errors的设置改成1就搞定了

今天吃饭前，上网管机，惊现存储监控的页面上面闪红灯，紧急赶往机房一看，一台netapp2050的机头a处于关机状态，于是连机头b查看，机头b的cf status状态是FAS2050B has taken over FAS2050A. 目前存储处于机头b接管状态。

于是又输了几条命令查看了下机头b的状态，当输入stats show 之后，没有出现命令行，ctrl+c也无法退出到命令行，断开终端重连输入用户名和密码后还是处于无命令行状态，顿时抓狂。

联系了下售后，决定先找机头a当机原因，起出机头a，由于机头a处于Waiting for giveback状态（ctrl+c重启后autoboot还是这样），无命令行，web也无法进去，直接用nfs连也无法通过。

到此为止，基本情况就是这样，机头a处于Waiting for giveback等待状态，需要机头b进行giveback才能回到正常工作状态，但是进行这个操作必须在机头b进行命令操作，但是机头b无论串口还是telnet都无法出现命令行。

抓狂了一阵后，忽然想到rsh可以直接写命令进去，试了下
rsh 10.10.1.1 -l root:root rdfile /etc/log/messages

果然有戏，把机头a的日志给读了出来了，一看原来nvram的电池检测到问题，自动关机了
Thu Apr 2 20:00:27 CST [FAS2050A: kern.shutdown:notice]: System shut down because : “NVRAM BATTERY FAILURE”.

把日志发给售后，netapp那边一开始说发配件换电池把，后来又打电话说无法判断是电池还是充电模块问题，干脆换机头把。 …说等会给我确定送货时间，我一琢磨下一工作日岂不是要4天后才能搞定了 。
等了一会，售后又打电话过来说netapp那边分析下来应该属于固件版本太低的问题，这个版本固件可能有点bug，电池是应该好的，让我直接giveback。

没办法客服的话总是要听的，rsh 10.10.1.2 -l root:root cf giveback 结果提示
Partner not waiting for giveback, giveback cancelled.
To do a giveback without checking for partner readiness, please either set optio
n “cf.giveback.check.partner” to “off” before doing “cf giveback” again, or do ”
cf giveback -f”.

The first choice disables checking for all future “cf giveback”, until it’s turn
ed back to “on”. The second choice is good for this giveback only.

客服说我插拔过机头用cf giveback -f，咱照做，果然有反应了
在机头b上面cf status，目前状态是
FAS2050B has taken over FAS2050A, giveback in progress.
giveback is in module “snapmirror”, 118 of 131 modules.

一阵等待后，提示ready for giveback，终于真不容易。。。。
继续 cf giveback
哗啦啦一堆信息滚过之后终于
Cluster enabled，2个机头都up了

最后按照客服提示options autosupport.doit 2000669538 导出一份autosupport报告发了过去。
客服说下周安排过来升级固件。

流水账就此结束，幸亏发现的及时，没有造成什么后果，这次经历之后我乖乖的还是把autosupport邮件名单添加了一份我的手机邮地址，可怜每个星期天半夜要被骚扰一次了。

今天在给一朋友搞个环境，发现系统时间永远比现在时间快8小时
date 输出 后面是GMT+8。不知道装系统的时候怎么选的
/usr/sbin/ntpdate time.nist.gov 结果无用，tzselect重新选择Asia/Shanghai也没用。
cat 了一下/etc/sysconfig/clock发现ZONE还是GMT+8，手工改成Asia/Shanghai结果还是没用
最后cat了下/etc/localtime 发现有点猫腻
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime 了一下终于搞定，真是个奇怪的毛病

近期在上squid，由于访问量集中在一台主机上，虽然经过了一些优化但是还是大量存在timewait的链接。打算在细挖下内核的一些网络参数的优化。目前还在调整中，如果照着修改的话先cat 备份下你系统现在的值
1.可以改变滑动窗口的大小 (默认应该就是“1”)
echo “1″ > /proc/sys/net/ipv4/tcp_window_scaling

2.修改内核共享内存限制 (新的系统应该默认就是这值)
echo 4294967296 >/proc/sys/kernel/shmall
echo 68719476736 >/proc/sys/kernel/shmmax

3.可使用的代理端口
echo “1024 65000″ > /proc/sys/net/ipv4/ip_local_port_range

4.禁止广播和ping入
echo “1″ > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo “1″ > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

5./proc/sys/net/ipv4/netfilter/ip_conntrack_max 改大到 268435456 默认只有65536 (这个就是连接跟踪表，一味的改大反而会增加系统的负载，一般来讲默认值也够，正确的优化方向是加快连接的关闭释放资源，我这只是在优化初期临时改大。注意/proc/sys/net/ipv4/ip_conntrack_max的值要大于这个值)

6.echo “1800″ > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
默认确立连接会在5天后失效，改为半小时后失效，减少ip_conntrack的有效连接数量。

7.echo 1 > /proc/sys/net/ipv4/tcp_syncookies
防范SYN DDOS攻击，打开TCPsyncookies,CENTOS4以上的内核是支持的。

8.echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog
SYN列队长度，不要设置太高，会消耗相应的内存。

9.echo 3 > /proc/sys/net/ipv4/tcp_synack_retries
SYN重试次数。

10.echo 3 > /proc/sys/net/ipv4/tcp_syn_retries
SYN重试次数。

还有一些没深入研究的
echo 600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo 120 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo 120 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout

情况是这样的，在升级ie8之后查看网页发现有2块乱码，看了看源代码，发现是调用的JavaScript

<script language=”javascript” type=”text/javascript” src=”http://www.abc.com/api/javascript.php?key=bbs_jinpai” charset=”utf-8″></script>

2个乱码区块都是以charset=”utf-8″方式调用的，查看了数据源，又发现这2个区块原本都是gb2312编码然后iconv转换到utf8的，于是改为不转换，仍然以gb2312输出，然后ie8以charset=”utf-8″方式调用竟然显示正常，不过其它浏览器就乱码了。最终跳过iconv以gb2312输出然后用charset=”gb2312″调用都正常了。

总结：如果输出是gb2312然后转换成utf8方式的js，在ie8下面以charset=”utf-8″调用是乱码，只有原生输出是utf8的才正常。应该是个bug