Blog V2.0.0发布
[
| 2011/02/27 14:41]
| 2011/02/27 14:41]
查看了下之前的升级编号，发现之前版本号升级过快，所以改动一下，之前的1.0,2.0分别对应1.1和1.2，依次类推，本次更新博客升级为2.0.0版。
最近一段时间博客版本升级不多，一方面是在做别的东西，另一方面是刚开始自己搞的框架实在是扩展性很弱，于是决定将博客在Codeigniter框架下重写。本次更新内容如下：
1，博客主程序重写，采用Codeigniter2.0作为框架。
2，写了一个php扩展：botfilter，增加函数sn_check_bot()，用来检查来访者是否为蜘蛛，对于蜘蛛的抓取不再计入访问量。
3，页面左栏访问量处增加“今日访问量”栏。
4，重写博客日志记录模块，之前blog日志与webserver日志重复，现改为只记录博客运行过程中信息。
5，优化数据库操作。
6，SEO优化，减少页面不相关重复文字。
7，其他bug修正和优化。
本次调整博客外观变化不大，主要是整体重写和一些优化以及修正。
最近一段时间博客版本升级不多，一方面是在做别的东西，另一方面是刚开始自己搞的框架实在是扩展性很弱，于是决定将博客在Codeigniter框架下重写。本次更新内容如下：
1，博客主程序重写，采用Codeigniter2.0作为框架。
2，写了一个php扩展：botfilter，增加函数sn_check_bot()，用来检查来访者是否为蜘蛛，对于蜘蛛的抓取不再计入访问量。
3，页面左栏访问量处增加“今日访问量”栏。
4，重写博客日志记录模块，之前blog日志与webserver日志重复，现改为只记录博客运行过程中信息。
5，优化数据库操作。
6，SEO优化，减少页面不相关重复文字。
7，其他bug修正和优化。
本次调整博客外观变化不大，主要是整体重写和一些优化以及修正。
Codeigniter 从1.7.2升级2.0过程中关于url的问题
[| 2011/02/18 11:20]
| 2011/02/18 11:20]
昨天在从nginx1.7.2升级2.0的过程中发生了一个问题，不管url是什么，都会直接调用default_controller。经排查，问题发生在system/core/URI.php里面，在65行开始的一段代码里，是为CLI方式运行CI写的一段代码，在这里，程序被判断成CLI模式运行，然后试图获取_parse_cli_args，为空，于是调用default_controller。
我使用的webserver是nginx，在配置文件里用urlrewrite去掉了index.php，CI配置文件中的uri_protocol使用的AUTO。
CI2.0中判断是否为CLI方式运行的方法是判断$_SERVER['argv']是否为空，不为空就是CLI，为空就不是。我查php手册，上面是这样说的：When the script is run on the command line, this gives C-style access to the command line parameters. When called via the GET method, this will contain the query string. 也就是说$_SERVER['argv']不为空的时候还有一种可能，就是GET方式访问网页，那么该元素中的数据就是query string。也就是说CI2.0默认认为不能使用传统的query string方式，否则会导致误判为CLI。
然后继续分析，在nginx中rewrite的规则是********/index.php?$1，注意，用的是问号而不是斜杠，这是nginx的问题，假如用斜杠的话nginx会试图寻找index.php文件夹下的目标文件，会导致404。也就是说比我我请求的是http:/*****/clock，在ci那变成了http:/*****/index.php?clock，所以在判断时$_SERVER['argv']为clock，于是被判断成CLI，而在_parse_cli_args中，又是从$_SERVER['argv']数组的第二个元素开始取，clock作为第一个元素没有被取到，自然_parse_cli_args取到的是空，导致调用了默认控制器。
综上，有两种修正方法，方法1是暂时注释掉URI.php中判断CLI的那一段，方法2是更改config.php中的uri_protocol为QUERY_STRING。当然还有一种方法是修改nginx的rewrite规则，不使用问号，不过这个我不知道怎么改。
我使用的webserver是nginx，在配置文件里用urlrewrite去掉了index.php，CI配置文件中的uri_protocol使用的AUTO。
CI2.0中判断是否为CLI方式运行的方法是判断$_SERVER['argv']是否为空，不为空就是CLI，为空就不是。我查php手册，上面是这样说的：When the script is run on the command line, this gives C-style access to the command line parameters. When called via the GET method, this will contain the query string. 也就是说$_SERVER['argv']不为空的时候还有一种可能，就是GET方式访问网页，那么该元素中的数据就是query string。也就是说CI2.0默认认为不能使用传统的query string方式，否则会导致误判为CLI。
然后继续分析，在nginx中rewrite的规则是********/index.php?$1，注意，用的是问号而不是斜杠，这是nginx的问题，假如用斜杠的话nginx会试图寻找index.php文件夹下的目标文件，会导致404。也就是说比我我请求的是http:/*****/clock，在ci那变成了http:/*****/index.php?clock，所以在判断时$_SERVER['argv']为clock，于是被判断成CLI，而在_parse_cli_args中，又是从$_SERVER['argv']数组的第二个元素开始取，clock作为第一个元素没有被取到，自然_parse_cli_args取到的是空，导致调用了默认控制器。
综上，有两种修正方法，方法1是暂时注释掉URI.php中判断CLI的那一段，方法2是更改config.php中的uri_protocol为QUERY_STRING。当然还有一种方法是修改nginx的rewrite规则，不使用问号，不过这个我不知道怎么改。
VMWare克隆后Ubuntu的"No such device eth0"错误(重新安装vmtool时也有可能出现此问题）
[| 2011/02/15 14:55]
| 2011/02/15 14:55]
资料网址：http://blog.csdn.net/mwq1984/archive/2010/03/20/5399539.aspx
解决方法：删除/etc/udev/rules.d/70-persistent-net.rules，重启机器即可。原因是mac地址冲突。
解决方法：删除/etc/udev/rules.d/70-persistent-net.rules，重启机器即可。原因是mac地址冲突。
虚拟机中的ubuntu重装vmtool后导致的黑屏
[| 2011/02/15 14:53]
| 2011/02/15 14:53]
我用vmware虚拟了一个ubuntu当做开发服务器，没有安装图形界面，平时都是命令行。不过之前由于在上面做过framebuffer的开发，grub引导的时候里面有vga=788字样，也就是800*600*16分辨率。
今天vmware提醒我vmtool有新版本了，决定升级一下，结果升级后重启时就黑屏了，在grub引导项里修改引导参数，去掉vga=788改用文本模式启动，可以正常显示，不过分辨率字体什么的就都没有了。不知为何出现此问题。暂且记下。
今天vmware提醒我vmtool有新版本了，决定升级一下，结果升级后重启时就黑屏了，在grub引导项里修改引导参数，去掉vga=788改用文本模式启动，可以正常显示，不过分辨率字体什么的就都没有了。不知为何出现此问题。暂且记下。
