嘻嘻哈哈的部落格(blog)

uch(ucenter home)2.0出了
但是貌似还是没有解决1.5的版本不能导入wordpress日志的问题
刚才试了
出错：

获取数据失败，请参考服务器返回:
post_status, custom_fields, 1150, _edit_lock, 1235824019

1，串行端口终端
设备名称是/dev/ttySn(这里的n是数字0,1,2,3…..)
2，伪终端(PTY)
伪终端是指远程登录形成的终端，其控制台控制文件在目录/dev/pts下
命名从0,1,2,3,4……一直往后
你可以echo “OKOK” > /dev/pts/0看看效果
3，虚拟控制台(终端)
虚拟控制台是机器正常启动后自动启动的控制台
可以用Ctrl+Alt+F1到Ctrl+Alt+F6来切换(缺省只开6个虚拟控制台)
其设备控制文件分别为/dev/tty1、/dev/tty2、/dev/tty3、/dev/tty4、/dev/tty5和/dev/tty6
还有/dev/tty0是对应当前的虚拟控制台(终端)
4，/dev/tty
这个是指当前进程的控制终端
可以看做是到控制终端的链接
用tty命令可以看到当前这个shell的控制终端
5，/dev/console
这个是系统控制台
很多的系统信息会打到这里
一般情况下
/dev/console是指向/dev/tty0的

以前用mod_ssl+apache配ssl服务器碰到过这个问题
别人直接用ip:443端口直接访问
就显示了缺省的https的站点
按照我们配http服务器的逻辑
肯定是想把443端口和某一个域名绑定起来用的
这样别人不知道域名就无法访问到真正的https站点内容
但是直接在apache里用

这样搞是不行的
系统总是只认第一个虚机
然后把所有https到443端口的访问都丢到里面
看了下(apache)官方的文档
里面是这样解释的：

Why can’t I use SSL with name-based/non-IP-based virtual hosts?
The reason is very technical, and a somewhat “chicken and egg” problem. The SSL protocol layer stays below the HTTP protocol layer and encapsulates HTTP. When an SSL connection (HTTPS) is established Apache/mod_ssl has to negotiate the SSL protocol parameters with the client. For this, mod_ssl has to consult the configuration of the virtual server (for instance it has to look for the cipher suite, the server certificate, etc.). But in order to go to the correct virtual server Apache has to know the Host HTTP header field. To do this, the HTTP request header has to be read. This cannot be done before the SSL handshake is finished, but the information is needed in order to complete the SSL handshake phase. Bingo!

金步国同学翻译如下：
为什么不能在基于域名的虚拟主机上使用SSL?
原因很技术化，有点类似于”鸡和蛋”的问题。SSL协议层位于HTTP协议层之下，HTTP协议是被封装在SSL协议中的，当一个SSL连接(HTTPS)请求到来的时候，Apache/mod_ssl必须和客户端协商SSL协议参数(握手)，所以，mod_ssl必须查看虚拟主机的配置信息(例如允许使用哪些加密算法、服务器证书是哪个等等)，然后才能完成SSL会话通道的建立；但另一方面，为了确切知道究竟应该查看哪个虚拟主机，Apache又必须知道HTTP请求头的Host字段的内容，而这在完成SSL握手之前是不可能知道的。

闲暇无聊学着写过一个perl程序
用来从网上抓点东西下来
再改吧改吧，存到本地的文件里
最早打开文件用的是open
但后来为了直接在open时就设定打开的文件的权限
就改用sysopen
像这样：

my $save_u = umask();
umask(0);
if (sysopen(FH, $path, O_RDWR|O_CREAT, $fmode)) {
print FH ($data);
close(FH);
} else {
print “Couldn’t open $path for writing:$!
\n”;
return 2;
}
umask($save_u);

但后来发现写入的文件尾巴上老有点问题
最开始老以为是某个替换内容用的正则表达式有问题
但查了半天都没查出来为什么
把每一个正则替换前后的数据都打印出来了没发现问题
最后甚至于把写到文件里去的数据打出来
还是没发现问题
最后就只有落到sysopen这里
认为是写错了
最后把sysopen那一行改成

if (sysopen(FH, $path, O_WRONLY|O_CREAT|O_TRUNC, $fmode)) {

这下终于好了
不过到今天才真正想明白为什么出问题
是因为sysopen时少了个参数O_TRUNC
这样的话打开的文件原来存在的话
没有执行truncate工作
直接从前往后写
也就是覆盖原来的内容
这种情况下
如果新内容比老内容多的话不会出问题
因为原来所有的内容都给覆盖掉了
可万一新内容比旧内容少的时候
就会留下老内容的一段尾巴
所以我们从页面上看老是尾巴上多一点东西
至于O_RDWR改成O_WRONLY则是非必须的
原因是为什么呢
这是因为打开原来存在的文件的时候没有truncate掉原来的内容
所以写到最后一段
如果没内容写了
那么原来文件的最后一部分就留下了
所以呢解决的方法很简单
在sysopen的option参数中加上O_TRUNC即可

写了个简单的perl程序
用来转码(gbk->utf8，utf8->gbk)之类
其中涌到了perl包Encode
发现个问题
当调用Encode包中的方法decode的时候，出错了
代码是这么写的
$html = decode($charset, $html);
当执行到这里的时候就报错：

Unknown encoding: gb18030

上面代码里的$charset是通过Encode::Detect::Detector->detect方法检测到的某个文件的编码
这里是gb18030

最后是怎么解决的呢
装了个perl包：Encode::HanExtra
并在程序里加上

use Encode::HanExtra;

问题就解决了

一个同事的机器
插了4个G的内存条
但系统只能认到3个G
而且已经在boot.ini中打开了pae
还是不行

从这里(http://www.codesourcery.com/gnu_toolchains/arm/download.html)下载arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu的软件包
从http://www.busybox.net/下载busybox源代码之后
解开
make menuconfig后出错

“gcc: error trying to exec ‘cc1′: execvp: No such file or directory”

是因为CONFIG_CROSS_COMPILER_PREFIX设的不对
应该是像这样：“/pathto/arm-2009q1/bin/arm-none-linux-gnueabi-”

产品有些较真的人
作squid压力测试
发现前台squid的access_log里面
状态是MISS的数量
跟后台real server(nginx)里的access_log里的访问记录条数对应不上(要多一些)

然后就怀疑squid也许会有问题
因为有些不在squid的cache里的请求没有能穿透squid打到后面的nginx上

经过仔细察看
发现squid里有同一时间、多个请求访问同一个不在squid的cashe里的对象
这时，squid在log里记的是“MISS”
但squid去后台real server(nginx)只取一次数据
(或者也是同时多个请求一起取，但nginx的access_log只记录一次)
毕竟
squid返回的是200状态嘛

某台机器出一诡异现象
/dev/null变成了一个常规文件！
导致某些服务不正常
我登陆上去

mv /dev/null /dev/null.xxx
mknod /dev/null c 1 3
chmod go+w /dev/null

然后就好了
只是为什么/dev/null会突然变成常规文件呢
没搞明白

前面碰到的问题
其实大概原因是这样的
Linux1–>vpn1<-->vpn2–>Linux2
vpn1和vpn2之间是走公网搭的一个vpn连接
这样
当从Linux1上ssh连接到Linux2上的时候
登录正常
当某个命令需要从Linux2返回大量的数据回Linux1的时候
由于某些ip包大小大于mtu值
而且被置DF位(不允许分片)或者是ip包允许分片但是vpn1或vpn2不允许分片的ip包通过
所以导致Linux1收不到其他的大ip包
导致看起来是ssh session挂掉
其实
tcp层有路径最小mtu值发现功能
为什么没生效呢？
其实不是这样的
比如当Linux2回来的大包分成1500一片到达vpn2
vpn2上还要给其打上4个字节的GRE头(如果vpn用的GRE通道的话)
再加上外层的20字节的ip头
这一下就超过vpn1公网(vpn是通过公网连起来的)以太网口的mtu值1500!!
于是返回“MTU of next hop: 1500”的错误
这样的话Linux2还会以1500来分片发送大包
这样循环下去，Linux1永远也不会收到来自Linux2的大的ip包
ssh session自然就“挂”了

原因明白了
那么解决起来就容易了
无非是改小mtu值嘛
那改成多少合适呢
很简单
改成1500-4-20=1476就行(其实小于这个数也行，不过mtu自然是要最大的)
于是ifconfig eth0 mtu 1476
再ssh登录
dmesg
都没问题了，搞定