最近将开发环境从Kubuntu 12.04升级到13.04，整个过程基本顺利。然而在使用过程中，逐渐发现一些有问题的地方，升级实际上导致了一些问题。例如Apache出现的问题。
升级后，Apache运行php脚本时全部失败，在log中可以看到以下一些类似的信息：
SoftException in Application.cpp ...
premature end of script headers...
解决方法也比较简单，将libapache2-mod-suphp模块删除后重新安装即可，没有去深究其中的具体原因。从中也可以看出：linux各版本目前作得都比较不错了，可是还是总有一些小问题会时不时出现并困扰你，让你去折腾，这可能也就是为什么linux始终无法进入主流消费者领域的原因吧。
将Kubuntu从12.04升级到13.04后，（在终端）运行程序会出现以下告警信息：
Fontconfig warning: “/etc/fonts/conf.d/99-language-selector-zh.conf”, line 11: Having multiple values in <test> isn’t supported and may not work as expected
检查该99-language-selector-zh.conf文件，发现在第一个<test name=”family” compare=”contains” >内定义了多个<string>参数，因此仅需要将这个项拆成多个family项即可，例如下面的修改：
<test name="family" compare="contains" > <string>Song</string> </test> <test name="family" compare="contains" > <string>Sun</string> </test> <test name="family" compare="contains" > <string>Kai</string> </test> <test name="family" compare="contains" > <string>Ming</string> </test>
采用SIP-INFO消息来传递DTMF信号，似乎只是Cisco的定义，没有一个成文的标准，但是目前主流的SIP厂家基本都遵循了相同定义，主要采用‘Signal’参数传递DTMF值：
Signal=1
Duration=160
其中，Signal与DTMF信号对应如下：
DTMF Signal ------------------------- 0--9 0--9 * 10 # 11 A--D 12--15 Flash 16
这种映射关系与RFC2833规范一致。但实际上，SIP-INFO既然是文本消息，其实没必要进行转译。例如，传递‘*’信号时，目前的处理是：
Signal=10
Duration=160
这样的定义非常不直观，完全可以直接传递，如下：
Signal=*
Duration=160
SIP-INFO这样传递显得非常直观。RFC2833二进制协议，只能进行定义转换，但是SIP本身是文本协议，足以进行文本性描述。可惜当初不知道为什么非要按照2833方式进行定义，也许这就是为什么这种方式始终没有成为正式规范的原因。
放下了工作，花了几天时间，终于看完了“史蒂夫 乔布斯传”，实实在在地被震撼了。毫无疑问，乔布斯是有很多毛病的人，甚至如文章所说，有时候他其实就是一个混蛋。
可是他对伟大产品的追求、坚韧不拔的毅力、对历史的使命感，是一般人无法企及的。简直让人高山仰止。他实在是有资格蔑视微软，认为微软从没有创造过伟大产品。为了创造伟大的产品心无旁骛、艰苦卓绝的努力，这种非常纯粹的精神追求，也是普通人难以承受的，而乔布斯一生如此，实在让人难以置信！天妒英才！天妒英才啊！！
在我们这个把盗版叫做微创新、到处是鲜廉寡耻的产业流氓的环境中，我们盛产浩浩荡荡地“走过人文和科技交叉点”的傻逼！
我们与别人的差距，不是产业规模的差距，不是技术能力的差距，更不是生产工艺的差距，而是思想和文化的差距、是历史使命感的差距。这种差距让人非常悲哀、非常气馁，也让人对乔布斯由衷地产生敬意！
虚拟机中的CentOS6.4编译安装增强功能时，有一些包需要安装，并且有个特殊的配置。相比之下，openSUSE非常好，默认就直接支持了vbox增强功能。
首先转变成su用户，然后进入目录/media/VBOXADDITIONS_4.1.12_77218（不同的virtualBox版本可能会有不同的目录），然后执行以下命令即可：
yum install gcc kernel-devel
export KERN_DIR=/usr/src/kernels/2.6.32…. <– 取决于版本号
yum install kernel-devel-2.6.32-… <–编译错误时会提示安装哪个版本
cd /media/VBOX… sh ./VBoxLinu….
2013-12-16更新：
在升级CentOS6.5后，编译增强功能会遇到一个编译opengl出错的提示，需要增加几个与drm相关的软连接：
# cd /usr/src/kernels/2.6.32-431.el6.i686/include/drm/
# ln -s /usr/include/drm/drm.h drm.h
# ln -s /usr/include/drm/drm_sarea.h drm_sarea.h
# ln -s /usr/include/drm/drm_mode.h drm_mode.h
# ln -s /usr/include/drm/drm_fourcc.h drm_fourcc.h
基本上与mysql数据库是完全兼容的，各项命令以及库的名字都与mysql相同。当然目前还没有深度应用，不知道在库、api等方面是否完全兼容。
启动数据库：
service mysql start
修改root用户密码：
mysqladmin -u root password "xxxx"
将数据库加入自动启动列表：
chkconfig --add mysql <-- Redhat/CentOS/openSUSe 或者 update-rc.d mysql defaults <-- Debian/Ubuntu
访问数据库：
mysql -u root -p
时间过得真快！从U公司离职，仿佛还是昨天发生的事情。
两年过去了，回头看看，自己真是在一个不太好的时间点选择了创业，非常鲁莽。这两年无论生活还是工作，都发生了巨大的变化，这些变化造成的压力有时候显得实在过于沉重。
希望接下来的日子会好一些。
传统电信网的各项规范往往经过了很多专家的讨论以及厂家的验证，因此显得比较严格和规范，例如传统的ISDN规范，定义都很明确。
而因特网的各项规范对比之下就显得很随意，往往是一个规范出来之前就考虑不周全，然后根据情况，又补充出一堆的规范。即使这样，仍然是显得有很多漏洞，或者说有很多不规范、不明确的地方，导致各厂家各说各的道理，给互联互通造成很大的困扰。
当然不是说传统电信规范没有漏洞或者定义含糊的地方，只是相比之下，因特网的规范实在是过于随意。
比如说SIP呼叫中的主叫号码。
在电信网规范中，与主叫相关的号码定义非常明确，主要就这么几个：主叫号码、原主叫号码以及显示号码。各号码的应用场景也非常明确，号码格式中的显示属性等也很明确。
在SIP规范中，与主叫相关的头域有这么几个：From, Contact, P-Asserted-Identity, P-Preferred-Identity, Remote-Party-ID等。这些定义要么没有明确规范好，要么就是多次一举，多半是RFC定义者遇到情况时，拍脑袋一想：算了，加个新的定义搞定吧。结果就让人很无语了。
From和Contact在标准的SIP code规范RFC3261中有明确定义，通常我们都认为From域中携带主叫号码，可惜规范并没有明确限定，因此有一些厂家往往在Contact域中携带主叫号码，而在From域中只携带地址信息。
而显然在实际应用中又遇到一些主叫号码显示的场景（估计主要是电信专家考虑3GPP网络的各项应用时，遇到了与传统主叫号码类业务的冲突），于是乎RFC3325规范就粉墨登场，一举增加了P-Asserted/Preferred-Identity两个头域，也是用来携带主叫号码信息。其中，P-Asserted-Identity主要在信任域的server之间、proxy之间、server与Proxy之间进行传递，而P-Preferred-Identity主要在UA与server/proxy之间传递。看，无聊不？折腾不？
而在正统的P-xxx-Identity头域出来前，民间的野路子显然也遇到了同样的主叫号码类业务的问题，于是乎定义了Remote-Party-ID，并基本参照了ISDN的一些定义，例如号码是否显示等属性，很多SIP厂商已经很high地支持了这个定义，比如说Asterisk。发现没？有了这个定义，还要P-xxx-Identity等定义干什么呢？但是不幸的是P-xxx-Identity已经是正式RFC规范，而Remote-Party-ID还停留在draft-xxx-04阶段（目前已经超时，不知道还会不会升级到正式RFC规范），因此SIP厂商不得不同时支持上述各个定义了。
我有没有提到：有些SIP设备在From/Contact等常见域中根本不携带号码，只在www/proxy-authorization中携带鉴权用户的号码，往往也就是作为主叫号码？
晕倒吧！
网上的一些文档大部分是基于其他linux的版本，因此对比之下配置比较复杂，让人望而却步。而Ubuntu则已经将一些基本的配置都打包好了，只需要稍做修改即可。
以下配置基于Ubuntu10.04，全部从官方软件中心下载安装。采用Postfix+Dovecot搭建邮件系统。请先切换到root用户安装和配置。
apt-get install postfix
安装时，会提示选择类型。一般选择”internet site”，输入网站域名即可。安装后，先不要着急配置postfix，我们在后续dovecot安装成功后，大部分配置会自动完成。
一般网文介绍是直接安装dovecot，实际上Ubuntu提供了与postfix配合的dovecot包，因此请按以下方式安装：
apt-get install dovecot-common dovecot-postfix
安装时，系统会自动根据dovecot的要求，对postfix进行配置。
配置文件为：/etc/postfix/main.cf。如果不对email进行限制的话，其实已经不用再配置了。下面我们修改该配置文件，增加一些额外的控制，例如用户邮件大小等：
mailbox_size_limit = 20000000 <--限定邮件账户不超过20Ｍ字节 message_size_limit = 200000 <-- 每封邮件不超过20K字节 myhostname = mail.xxxx.com mydomain = xxxx.com
一般也不需要配置，但是在使用gmail托管时，ssl/tls似乎没起作用，因此稍作修改采用普通访问方式即可。注意，此时dovecot的配置文件是/etc/dovecot/conf.d/01-dovecot-postfix.conf
listen = * disable_plaintext_auth = no
缺省情况下，dovecot没有被配置为自启动，因此我们需要手工添加：
update-rc.d dovecot start 99 0 1 2 3 4 5 6 .
email用户账户就是当前Ubuntu的用户。建议对email用户单独处理，并设置在mail组内，设置单独的用户目录等，如下所示，创建一个名为support的用户：
mkdir /home/mail-users useradd -m -d /home/mail-users/support -g mail support passwd support
如果需要支持pop3的話，需要安裝以下軟件：
apt-get install dovecot-pop3d
由于工作上的需要，最近两天折腾openssl来实现一些信令加密解密的事情。总体来说，openssl是个很不错的库，也是个很不错的工具。使用openssl做tls客户端编程没有太大问题，而实现tls服务器端则有些地方需要注意。
首先要注意的一点就是：在握手之前（SSL_accept），绝对不能采用非阻塞方式。握手成功之后，才可以将socket修改为非阻塞方式，否则握手不会成功，服务器总是会向客户端返回“Engypted alert”消息并结束握手。
如果是在windows环境生成证书和密钥，建议使用SimpleCA工具，很好用。同时要注意：（1）客户端应安装或者使用该工具生成的根证书，例如ca.crt。（2）服务端需要使用生成的服务端证书和密钥，即.crt和.key文件。（3）生成证书时（无论是根证书还是服务端证书），Common Name都必须要设置为当前服务器的IP地址或者主机名，否则双方握手时，可能产生”certificate name mismatch”等错误。（4）如果需要将证书导入windows系统，必须导入为“受信任的根证书颁发机构”类型。
如果是Ubuntu等linux系统，可以直接安装使用openssl生成证书，如以下命令：
生成根证书： openssl genrsa -out ca.key 4096 openssl req -new -x509 -days 3650 -key ca.key -out ca.crt 生成服务端证书和密钥 openssl genrsa -out server.key 1024 openssl req -new -key server.key -out server.csr openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
理论上来说，可以将.crt和.key文件合并在一起，设置为.pem文件。不过实践证明，openssl的API是要求SSL_CTX_use_PrivateKey_file函数来加载密钥文件的，否则握手还是会出问题（当然，也可能是需要另外单独的设置）。