FeedBurner RSS
联系博主
Email or Gtalk:
Win32版本的锐捷客户端zRuijie4GZHU
July 29, 2009花了几天时间，将zRuijie4GZHU的代码用Win32 API封装好了。 怎么突然给“万恶“的Windows开发程序呢，呵呵算是一时冲动好了，因为此前对Windows的API基本一无所知，虽然大二的时候C++的课程教了一点MFC，不过离开底层API来说MFC，真的很腾云驾雾，转眼就全忘记了，交课程报告时候用VS的Wizard大概地弄个两个窗口，甚至说不清一个控件是怎么被创建的……画上去的？嘿嘿…… 这次做Win的程序算是为了了解一下Win下面的模式，程序使用纯SDK API来写。开着虚拟机，开始的时候用Dev CPP来做，但没一会就忍不了那个编辑器的白痴了，还好Devcpp提供了项目的Makefile，于是用Notepad++来弄代码，开着个cmd窗口来编辑；最后还是把代码弄到Linux来，装了个mingw来cross，用gvim来写代码才有快感。程序的resources使用ResEd来做，很不错的小东西，用wine来跑一点问题都没，哈。 写win32过程我想最多的就是GTK，感觉Win32那些API很有考古的感觉，比如说指针类型，不知道有没有人统计过究竟微软发明了多少个类型，LPSTR，LPCSTR，INT_PTR，LPVOID TMD匈牙利命名法，就不能用好看一点的名称～ 对比起来，win32最原始的地方应该是消息处理过程吧，看着形态怪异的DlgProc，很郁闷的感觉；GTK只需要按事件类型来注册回呼函数，所以我写的的Proc基本都是用函数把处理过程引了出来。 代码依然扔在Google Code：http://code.google.com/p/zruijie4gzhu/
简单配置nginx+fastcgi后端的WordPress服务器
July 24, 2009Update: nginx+php的环境可以更快捷的方法完成，参看Nginx + PHP (via php-fpm) on Ubuntu 环境最佳实践 比起传统的LAMP Web服务构架，nginx替换Apache能够在同样硬件配置情况下提高10倍的并发性能；PT尝试在Arch下用nginx简单搭建一个让wordpress运行的LNMP环境的笔记：（实际上nginx+fastcgi的架构在目前看来性能并不高，甚至比apache+mod_cgi差，也许nginx做前端服务，apache做后端处理合适一点[误]） Update：nginx+fastcgi跑服务的组合通常用在一些低端的vps上，其内存甚至不到100M，所以apache等庞物是不适合的。按下文方法启动的fcgi只有一个worker进程，而且nginx配置当中没有fastcgi的缓冲，所以会有性能低下的感觉，其实可以通过PHP_FCGI_CHILDREN环境变量等来进行优化。另外推荐使用这里提到的启动脚本来启动php-cgi。参考一些nginx调优方案，再加上一些Wordpress Cache之类的，一台64M的vps足够跑上一打wordpress博客了。 安装nginx。 nginx在源里面，很简单就安装完成； 1 /etc/rc.d/nginx start 启动nginx的服务，因为有默认的配置，这时用浏览器看看http://localhost，可见到nginx的错误页了，完成； 安装php 安装php也是从源里来的，至于运行php，按arch wiki推荐的方法是使用fcgi，顺便装上，运行： 1 cgi-fcgi -start -connect localhost:9000 /usr/bin/php-cgi nginx的默认目录在/srv/http/nginx，在里面新建一个index.php，包含简单的代码： 1 2 3 <?php phpinfo(); ?> 然后我们要让nginx使用php来解释这个文件，编辑/etc/nginx/conf/nginx.conf 配置nginx的重点就是这个文件，但先不管，在适当的地方贴入这段： location ~ \.php$ { root html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } 重启一下nginx 1 [...]
转换到新域名apt-blog.net
July 16, 2009在Godaddy买的国际域名，颇有一波三折的感觉，Godaddy做的域名停泊似乎颇有问题，折腾了两天，用Email跟他们客服打交道，说来说去都是废话，不过收获就是彻底搞清楚了域名的A记录、CNAME、MX、NS等概念……-。- ns49.domaincontrol.com是Godaddy的NS，这两天在他们的控制面板搞了搞去，查询的时候始终多了个68.178.232.100的记录，就是说使用apt-blog.net访问的时候，只有50%的概率成功（很氧化钙）……跟他们客服说了半天也没弄好。 [pentie@ptdesktop ~]$ nslookup apt-blog.net ns49.domaincontrol.com Server: ns49.domaincontrol.com Address: 216.69.185.25#53 Name: apt-blog.net Address: 222.73.161.75 Name: apt-blog.net Address: 68.178.232.100 后来听了felix猫的推荐，把域名解释改到棒子提供的DNSEVER，终于正常了： [pentie@ptdesktop ~]$ nslookup apt-blog.net Server: 202.192.18.1 Address: 202.192.18.1#53 Non-authoritative answer: Name: apt-blog.net Address: 222.73.161.75
低调发布个锐捷客户端：zRuijie4GZHU
July 8, 2009zRuijie4GZHU Google Code：http://code.google.com/p/zruijie4gzhu/ 其实这个项目的目标不是非常明确，至少到目前为止，能在Linux下的使用的锐捷兼容客户端已经有mystar、 ruijieclient、mentoHust（还有很多，单纯Google Code上以“锐捷”为标签的就一堆了……），还有基于QT、pygtk开发的图形界面程序，可谓百花齐放，再开发一个版本出来理由似乎不太充分，只是为了一些美中不足：比如最有实力的mentoHust，其能支持到锐捷最新的3.7版本的协议，却不是开源方案；mystar则是年久失修，已经不能兼容现在的协议（不过其留下的代码让后来的开发者得到很大的指引，在此对作者Rijndael&byhh表示敬意）；至于此前一直使用的Ruijieclient，其实也有点问题，一直掉线，查看上网明细，每次在线都只有1分29秒就被踢了，说明协议兼容问题。虽说Ruijieclient有“智能重连”功能，但是重连跟掉线是两回事，不能说会重连就说解决了掉线问题，花心思研究协议才是正道。 也许也就在于类似问题的出发点不同吧，虽然PT加入了Ruijieclient的项目，但一直没有参加过代码开发，毕竟一提出任何意见就互相反对的人之间很难合作，所以考完试后就花了一天时间，把锐捷协议移植到PT的“z-框架”下。虽然分析下来这个兼容问题是小事情，就是所谓的serial number的初始值以及success key的提取位不对，不过我实在不喜欢Ruijieclient的框架了，而且对自己熟悉的“z-框架”代码维护起来有快感的多。 “z-框架”是指PT依次开发神州数码、联想、锐捷几个客户端一直沿用下来的一些模式，所以zRuijie4GZHU的代码理论上跟其他锐捷相关程序是没什么相似的。除了从mystar里面沿用过来的两个数组照样copy外，PT把mystar开发时候通过反汇编得出来的Alog、Blog算法函数都重写了一次，比原来汇编式的代码的效率和可读性要高得多（分析过程中发现原来有几行的代码是多余的），两个函数摘抄在本文后面，希望对其他的锐捷开发者有用。 zRuijie4GZHU的目标应该跟Ruijieclient这些不同，Ruijieclient是面向通用的锐捷协议，要做到全球通用其实难度不小的，而zRuijie4GZHU，也正如其名，是为广州大学的锐捷而兼容的，如果能在其他学校使用，那估计是意外。 PT的开发理念是K.I.S.S，zRuijie4GZHU没有什么复杂概念，比如DHCP，只有是和不是DHCP模式，没有什么0、1、2、3模式，更没有配置文件，软件是执行文件和脚本的统一体，缺一不可。 OK，有需要的用户可以查看项目wiki的用户手册吧，下面是PT改写的锐捷Ablog和Blog算法函数： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 /* * [...]
深入了解校园网802.1x认证的EAP协议(2)——神州数码认证细节
July 4, 2009各地的校园网认证有很多种品牌，正因为EAP可扩展的特点，基本上每个品牌的认证方案都会互不相同。从商业角度考虑，当使用了某个品牌的认证系统后，很可能就不能使用其他牌子的交换机了；而对用户来说，这不仅带来了以后维护的问题，还因为各个厂商开发的EAP客户端的投入不同，质量良莠不齐，占用内存大、限制多（比如有些为了防止用户开代理，加入多网卡检测，结果用户就不能使用虚拟机、手机GPRS Modem等）、不支持非Win平台。 这就是我们研究这些厂商自定义的EAP协议的意义。 PT实现的神州数码Linux客户端项目主页：http://code.google.com/p/zdcclient/ 以下的说明是基于EAP协议过程的补充描述，如果不清楚EAP，可先读深入了解校园网802.1x认证的EAP协议(1)——EAP的总体流程。 神州数码的私有信息尾结构神州数码协议里面最特别的地方是有一段46字节的信息，其位于EAP报文后，属于EAPOL报文的尾端部分，在发往服务器的EAP_RESPONSE_IDENTITY和EAP_RESPONSE_MD5_Challenge两种报文里面都需要附上该46字节的信息以供验证。
Page optimized by WP Minify WordPress Plugin