本文同步自（如浏览不正常请点击跳转）：https://zohead.com/archives/wordpress-uyan-recent-comment-widget-v1-1 前两天写了一个友言近期评论的 WordPress Widget，初步测试还能用，但多次进行刷新，会出现不能正常登录之类的问题（Failed to authentication with uyan.cc、Invalid comments data from uyan.cc 之类的报错），而且原来每次都需要登录友言的后台管理严重影响速度，我也比较怕怕这样不断发请求会导致友言把我的脚本和博客给封掉，嘿嘿。 由于友言没有公开 API 给我等码农来调用，因此今天又花了点时间做了一些改进，弄了个 1.1 版本，原介绍文章在这： https://zohead.com/archives/wordpress-uyan-recent-comment-widget/ 1.1版本更新说明： 1、登录友言后台管理，得到近期评论等地方增加错误处理，如果服务端返回的 JSON 数据不对则报错 2、减少 PHP 本身的 error message 输出 3、将得到近期评论的功能分离为一个函数单独调用 4、登录成功之后保存得到的 cookies 到同目录下的 uyan_cookie.php 文件中方便下次直接使用，而无需再重复登录，如果 cookie 过期下次获取评论时失败则再重新登录 5、发查询近期评论请求时增加友言本身的管理地址作为 referer 此次增加了一个 uyan_cookie.php 文件用于保存 cookie，从下面的链接下载解压缩之后，请将此文件也上传到同一目录中（不上传的话 PHP 可能会报 require_once 出错），此文件默认为空，详细代码就不贴了，直接在下面下载查看吧。友言 的登录邮箱、密码、域名之类的修改请参考原始的介绍文章了。 这个是 1.1 版本的下载地址： http://miseal.googlecode.com/files/uyan_comments_v1.1.zip 当前的通过临时文件保存 cookie 方式应该还有改进空间，有任何问题欢迎指正咯 ^_^
Author: Uranus Zhou
PHP实现WordPress友言近期评论Widget
本文同步自（如浏览不正常请点击跳转）：https://zohead.com/archives/wordpress-uyan-recent-comment-widget/ 现在有很多人都使用 WordPress 来搭建自己的博客系统，其中有一些是像我这样使用 友言 这个社交评论插件来替代系统原始的评论框的，友言 评论框插件对一些主流的社交网站支持比较好，很是推荐，友言官网： http://uyan.cc/ 之前我写过一个修改 友言 插件实现完美与 WordPress Mobile Pack 插件配合实现移动版博客的文章，在这里仅供参考： https://zohead.com/archives/modify-plugin-wordpress-mobile-pack/ 但现在发现还是有一点不足，由于使用了友言评论框替代 WordPress 本身的，导致 WordPress 的 ”近期评论“ Widget（小工具）显示不了，因此小折腾一个晚上，靠着还依稀记得的 PHP 编程经历，写了一个简单的显示 友言 近期评论的 WordPress Widget，先看效果图（本博客右侧就有 ^_^）： 原理及代码： 实现原理比较简单，先用工具分析 友言 评论的后台登录和评论显示之类的 HTTP 包信息，然后用 PHP 的 fsockopen 来自己发送 GET、POST 请求实现在 WordPress 上列举显示已经存在的友言评论（备注：默认只显示已经经过审核的评论）。 由于中间有几步 GET 和 POST 请求，就找了个现成的 post-to-host 这个很小的 PHP 脚本来发 GET 和 POST 请求，下载地址： http://code.google.com/p/post-to-host/ 下面是主程序 uyan_comments.php 的代码： 代码本身比较简单，有些 PHP 基础就可以看懂了，把 uyan_comments.php 文件最上面的 $email、$password、$domain、$maxcomments 改为实际的 友言 后台管理的登录邮箱、密码、你的域名、显示的最多评论数（备注：默认为10条，如果改为小于0的值则不限制显示的评论条数），就可以使用了。你应该已经发现这个 uyan_comments.php 其实和 WordPress 没太大关系，完全也可以直接单独使用。 需要注意的是为了避免使用明文密码而可能导致的问题（安全第一 ^_^），上面的 $password 是 友言 后台管理时实际用到的加密过的密码。这个加密过的密码可以通过 Firefox 的 Live HTTP headers 插件之类的抓取 HTTP 协议头的插件或工具来得到。 得到友言的加密登录密码： 下面以 Firefox 的 Live HTTP headers 插件为例说明如何得到 友言 的实际加密的密码，打开 Live HTTP headers，该插件会自动开始抓取，然后用正确的邮箱和密码登录 友言 的后台管理，停止 Live HTTP headers 的抓取，在输出里就能找到地址为如下格式的 GET 请求，请求参数中就有加密的密码： http://uyan.cc/index.php/youyan_login/userAutoLoginCrossDomain?callback=jsonpxxxxxxx&email=xxxxx@xxxxx.com&loginPassword=xxxxxxxxxxxxxxxxx&rem=1&domain=xxx.com 其中的 email 段就是登录邮箱，loginPassword 段即为加密的密码，保存下该密码，修改 uyan_comments.php 文件中的 $email 和 $password 值。 Live HTTP headers 的抓取截图如下所示（后面的未显示完整）： 如何加入 WordPress Widget 列表中： 你如果有真正实现一个 WordPress Widget 的心思，可以用本代码加上 WordPress 的 register_widget 之类的接口来实现。无奈我是一个超级懒人，懒人就有懒人的办法，下面介绍的就是懒人的办法，哈哈。 首先下载本文最下面下载链接中的 post_to_host.php 和 uyan_comments.php，将 uyan_comments.php 中对应的 登录邮箱、密码、域名 改掉（参考上面），将这两个文件上传到 WordPress 根目录中（位置也可以自己修改），然后给 WordPress 安装 PHP Code Widget 插件，这是一个通用 Widget，添加之后，可以自行添加 文本、HTML、PHP 代码等，比较方便，插件地址： http://wordpress.org/extend/plugins/php-code-widget/ 安装之后，在 WordPress 管理后台的 外观 - 小工具 里就能看到名为 “PHP Code” 的小工具，将其托至右侧的 “第一小工具区域”，输入自定义的标题，然后加入以下代码保存即可（如果上传的位置不在 WordPress 根目录那请自行修改）： 重新访问 WordPress，如果上面的 登录邮箱、密码、域名 设定都正确的话，应该就可以出现类似上面效果图的评论列表。 不足和改进： 1、uyan_comments.php 每次访问时都需要登录 友言 管理后台，请求评论列表，因此速度会有些影响，这个有空再改进了。 2、由于需要在 Web服务器中使用 PHP 的 fsockopen 来发 GET、POST 请求得到评论列表，因此可能对 WordPress 博客的访问速度造成一些影响，如果 PHP 空间在国内还可以，像我这样空间在国外的就稍微悲剧点了，所以建议安装 WP Super Cache WordPress 之类的插件来实现更好的缓存加速，将影响尽量降低。 下载地址（115网盘）： http://115.com/file/beezjk3b 写博客好累，准备休息，HOHO，本文件为个人作品，有任何问题欢迎指正。 ^_^
bind2nd普通二元函数时无法使用引用类型参数的问题
本文同步自（如浏览不正常请点击跳转）：https://zohead.com/archives/cplusplus-bind2nd-reference/ 在使用 STL 的 find_if、count_if 等函数时会发现这些函数使用的参数不是普通的函数指针，而是 functional 函数对象，实际使用函数对象时可以自己定义一个仿函数来实现（实现带参数的 operator () 即可），这个相对比较简单就不写出来了。但有些情况需要直接使用普通的二元函数指针，这时可以使用 ptr_fun 将函数指针转换为函数对象作为 find_if、count_if 等的参数。 先看一个能正常工作的二元函数不使用引用类型参数的代码： 程序很简单，从 vector 中查找符合条件的 sss 对象，find_sss 就是要转换的二元函数指针，第一个参数是 sss 类，通过 ptr_fun 可以使本代码正常工作。 通过下面的运行输出能看出调用 find_sss 时进行了拷贝构造（本程序的编译环境为：Windows 7 32bit, Mingw gcc 3.4.5，Visual Studio 2010中稍有不同，主要在前面的拷贝次数上）： ---copy 0x22ff10 to 0x552a58 ---copy 0x552a58 to 0x552ad8 ---copy 0x22ff10 to 0x552ae0 ---copy 0x552ad8 to 0x552af0 ---copy 0x552ae0 to 0x552af8 ---copy 0x22ff10 to 0x552b00 ---copy 0x22ff10 to 0x552b08 ---copy 0x552af0 to 0x552b18 ---copy 0x552af8 to 0x552b20 ---copy 0x552b00 to 0x552b28 ---copy 0x552b08 to 0x552b30 ---copy 0x22ff10 to 0x552b38 before find_if ---copy 0x552b18 to 0x22fdd0 ---copy 0x22fdd0 to 0x22fd40 ---copy 0x552b20 to 0x22fdd0 ---copy 0x22fdd0 to 0x22fd40 ---copy 0x552b28 to 0x22fdd0 ---copy 0x22fdd0 to 0x22fd40 index: 2, value: 13 接下来就是实际碰到的问题了，如果将 find_sss 的第一个参数改为 sss 的引用，即第 24 行改为： bool find_sss(sss& s_chk, int val) 上面的代码就会编译出错（以 Visual Studio 2010 的错误输出为例）： C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\xfunctional(341) : error C2535: “bool std::binder2nd<_Fn2>::operator ()(sss &) const”: 已经定义或声明成员函数 with [ _Fn2=std::pointer_to_binary_function<sss &,int,bool,bool (__cdecl *)(sss &,int)> ] C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\xfunctional(335) : 参见“std::binder2nd<_Fn2>::operator ()”的声明 with [ _Fn2=std::pointer_to_binary_function<sss &,int,bool,bool (__cdecl *)(sss &,int)> ] test.cpp(43): 参见对正在编译的类 模板 实例化“std::binder2nd<_Fn2>”的引用 with [ _Fn2=std::pointer_to_binary_function<sss &,int,bool,bool (__cdecl *)(sss &,int)> ] 网上的码农和攻城师们基本都认为是 STL 本身的问题，传递引用类型参数会造成 reference to reference 问题。 几番尝试之后，发现的解决方法如下： 1、Visual Studio 2010下的不完美解决方法： 将第 43 行改为： iii = find_if(vvv.begin(), vvv.end(), bind2nd(pointer_to_binary_function<sss, int, bool, bool(*)(sss&, int)>(find_sss), 13)); 这样通过自己给 pointer_to_binary_function 设置模板参数避免编译出错，实际运行中会发现 find_if 查找可以正常工作了，但第 27 行中修改引用类的值会没有效果，因为这种方式不是真正的引用，仍然有拷贝构造，由于需要用到这些二元函数的场合一般不需要修改数据，使用起来没有太大问题。 2、gcc下的不完美解决方法： 如果 gcc 下用上面的改动，你会发现由于 gcc 下 pointer_to_binary_function 只有 3 个参数，无法顺利修改编译，但可以这样折中，将第 43 行改为： iii = find_if(vvv.begin(), vvv.end(), bind2nd(ptr_fun((bool(*)(sss, int)) find_sss), 13)); 通过强制类型转换来实现，稍显恶心，查找可以正常工作，但依然是拷贝构造。需要注意此方法如果在 Visual Studio 中使用会出错。 3、终极解决方案- 使用 boost 库： 首先头文件中增加： #include <boost/functional.hpp> 然后原来的第 43 行改为： iii = find_if(vvv.begin(), vvv.end(), boost::bind2nd(boost::ptr_fun(find_sss), 13)); 编译运行之后发现 find_if 查找可以正常工作，而且现在是真正的引用，只能说 boost 的 functional 相比 STL 的实在是好强大，哈哈。 运行输出如下（使用 Mingw gcc 3.4.5 编译），find_if 找到的值已经被 find_sss 修改： ---copy 0x22ff10 to 0x7f2a58 ---copy 0x7f2a58 to 0x7f2ad8 ---copy 0x22ff10 to 0x7f2ae0 ---copy 0x7f2ad8 to 0x7f2af0 ---copy 0x7f2ae0 to 0x7f2af8 ---copy 0x22ff10 to 0x7f2b00 ---copy 0x22ff10 to 0x7f2b08 […]
C++虚基类的实现验证
本文同步自（如浏览不正常请点击跳转）：https://zohead.com/archives/cplusplus-virtual-base-class/ 在C++的某些应用环境中，如果有多个派生类同时继承同一个基类，但只要想基类成员的一份拷贝，这样可以把对基类的继承声明为虚拟（virtual）的，以达到需要的目的，用 virtual 限定的继承即为虚继承，对应的基类即为虚基类，没有则为非虚基类。在派生类产生的对象中，同名的虚基类只产生一个虚基类对象，非虚基类则有各自的对象，需要注意虚基类和抽象类的区分。 另外特别需要注意的是一个基类即可以被用作虚基类，也可以被用作非虚基类，这纯粹看是否是虚继承（是否有 virtual 限定）。虚基类子对象是由最远派生类（也就是建立对象时所指定的类）的构造函数调用虚基类的构造函数进行初始化。如果一个派生类继承了多个基类，其中既有虚基类，也有非虚基类，则虚基类构造函数优先于非虚基类的构造函数，而不管实际书写顺序，而且如果该派生类的构造函数初始化列表中同时有对虚基类和非虚基类构造函数的调用，同样也是虚基类优先。 有关虚基类的其它说明请参考其它书籍咯，下面是测试的代码： 比较简单，Base2 和 Base3 分别派生自 Base，而且都是虚继承，Base4 同时派生自 Base2 和 Base3，但 Base3 前有 virtual，表示 Base4 对 Base3 是虚继承，Base4 对 Base2 是非虚继承。另外代码中比较特殊的一点是 Base 基类中去掉了默认构造函数，改为一个 int 参数的构造函数（第 8 行），因此 Base2 和 Base3 的构造函数的初始化列表中都需要增加对基类 Base 构造函数的调用，同样 Base4 需要调用 Base、Base2 和 Base3。 主程序中只是生成一个 Base4 的对象，上述代码的运行输出为： init Base 0x22ff34, value:22 init Base3 init Base2 destory Base 0x22ff34, value:22 由上面的输出可以验证虚基类的概念： 由于 Base2 和 Base3 都是对 Base 的虚继承，虽然 Base4 中分别调用了 Base2 和 Base3 的构造函数，但虚继承就表示基类 Base 只有一份拷贝，Base 只需要构造一次。另外由于 Base4 对 Base2 是非虚继承，对 Base3 是虚继承，尽管 Base2 看起来在前面调用，但由于 Base3 对 Base4 是虚基类，它的构造函数就需要先于 Base2 对调用，因此 ”init Base3“ 在 ”init Base2“ 前面。 接着对代码稍作改动，将 Base2 和 Base3 都改为非虚继承，Base4 中去掉对 Base 基类构造函数的调用： 第22行：class Base2 : public Base 第31行：class Base3 : public Base 第43行： Base4(int val) : Base2(val), Base3(val) 编译运行输出，结果为： init Base 0x22ff38, value:22 init Base3 init Base 0x22ff34, value:22 init Base2 destory Base 0x22ff34, value:22 destory Base 0x22ff38, value:22 可以看到由于 Base2 和 Base3 都不是非虚继承，Base 就被构造了两次。 在上面的基础上再做个小改动，把 Base4 对 Base3 的派生也改为非虚继承： 第40行：class Base4 : public Base2, public Base3 再次运行输出，结果即为： init Base 0x22ff30, value:22 init Base2 init Base 0x22ff34, value:22 init Base3 destory Base 0x22ff34, value:22 destory Base 0x22ff30, value:22 由于 Base4 对 Base2 和 Base3 都不是虚继承了，对 Base2 和 Base3 的构造函数调用就按实际顺序了。 这样虚基类的概念就算是比较清楚咯。 ^_^
MuDu and SuZhou trip on May Day 2012
Sorry, this entry is only available in 中文.
vector的push_back拷贝构造和空间占用分析
本文同步自：https://zohead.com/archives/vector-push-back-space-copy/ 这两天在实际程序中使用 STL 的 vector push_back 类对象时出现问题，偶尔发现 vector 在 push_back 时的调用类对象的拷贝构造函数和析构函数有点特别，简单做下分析。 程序代码： 功能很简单，main 中定义一个 sss 类对象和对应的 vector，然后在循环中改类成员的值，并依次 push_back 到 vector 中，类的构造函数、析构函数、拷贝构造函数中都加了对应的打印输出。循环运行了5次，往 vector 中增加了5个类成员。 实际运行输出如下： ---init sss 0x22ff20, value:11 ---copy 0x22ff20 to 0x5d2a58 size: 1, capacity: 1 ---copy 0x5d2a58 to 0x5d2ad8 ---copy 0x22ff20 to 0x5d2adc ---destory sss 0x5d2a58, value:12 size: 2, capacity: 2 ---copy 0x5d2ad8 to 0x5d2ae8 ---copy 0x5d2adc to 0x5d2aec ---copy 0x22ff20 to 0x5d2af0 ---destory sss 0x5d2ad8, value:12 ---destory sss 0x5d2adc, value:13 size: 3, capacity: 4 ---copy 0x22ff20 to 0x5d2af4 size: 4, capacity: 4 ---copy 0x5d2ae8 to 0x5d2b00 ---copy 0x5d2aec to 0x5d2b04 ---copy 0x5d2af0 to 0x5d2b08 ---copy 0x5d2af4 to 0x5d2b0c ---copy 0x22ff20 to 0x5d2b10 ---destory sss 0x5d2ae8, value:12 ---destory sss 0x5d2aec, value:13 ---destory sss 0x5d2af0, value:14 ---destory sss 0x5d2af4, value:15 size: 5, capacity: 8 ---destory sss 0x5d2b00, value:12 ---destory sss 0x5d2b04, value:13 ---destory sss 0x5d2b08, value:14 ---destory sss 0x5d2b0c, value:15 ---destory sss 0x5d2b10, value:16 ---destory sss 0x22ff20, value:16 结果分析： vector 每次调用 push_back 时都会拷贝一个新的参数指定的 sss 类对象，这会调用 sss 的拷贝构造函数，第一次的 copy 正常，而且 vector 的实际容量也由 0 变为 1。 第二次调用 push_back，通过输出会发现调用了两次拷贝构造函数，一次析构函数，原来 vector 此时判断容量不够，将容量扩大为原来的两倍，变为 2，并将原来的元素再次拷贝一份存放到新的内存空间，然后拷贝新加的类对象，最后再释放原来的元素。 第三次调用 push_back 时，vector 自动扩大为4，因此拷贝构造函数调用了3次，析构函数调用了2次，程序最终退出了时就析构了 5 次加本身的 sss 类对象一共 6 次。 参考： 由此看来，vector 的 push_back 在发现空间不足时自动将空间以 2 的指数增长：0 -> 1 -> 2 -> 4 -> 8 -> 16 -> 32 … 查找资料后得知，如此设计的主要目的是为了尽可能的减小时间复杂度；如果每次都按实际的大小来增加 vector 的空间，会造成时间复杂度很高，降低 push_back 的速度。 另外关于 push_back 为什么会执行拷贝构造函数，push_back 的原型为： void push_back(const _Ty& _Val) 参数是以引用方式传递，按说不会拷贝，但 push_back 实际实现中判断空间不足时是调用 insert 函数添加元素： void push_back(const _Ty& _Val) { // insert element at end if (size() < capacity()) #if _HAS_ITERATOR_DEBUGGING { // room at end, construct it there _Orphan_range(_Mylast, _Mylast); _Mylast = _Ufill(_Mylast, 1, _Val); } #else /* _HAS_ITERATOR_DEBUGGING */ _Mylast = _Ufill(_Mylast, 1, _Val); #endif /* _HAS_ITERATOR_DEBUGGING */ else insert(end(), _Val); } 更新： 2012-05-10： 近期在 Visual Studio 2010 中发现 vector 的实际空间增加顺序为：1 - 2 - 3 - 4 […]
解决socket在execl之后被自动继承的问题
本文同步自：https://zohead.com/archives/close-socket-after-execl/ Linux下的进程在创建子进程（fork）后，子进程会自动继承父进程的文件描述符，这种机制在没有 execl 运行时一般都没有问题，而且也比较方便在子进程中直接使用父进程中打开的文件描述符，但如果子进程通过 execl 类函数运行新的程序时，这些继承的文件描述符却没有被关闭，导致 execl 之后的程序中也有父进程中文件描述符的拷贝，有些情况就会出现错误。 由于 socket 也在这些文件描述符范围内，本文简单说下解决 socket 被自动继承的几种方法。 首先是测试程序，头文件就没列出来了。 父进程和子进程分别 sleep 10秒钟，方便外部查看打开的文件描述符，编译运行程序，使用 lsof 命令就可以看到子进程在 execl 之后的 sleep 进程中也打开了父进程的 socket 描述符（UDP连接），这不是我们想要的效果滴： [root@localhost ~]# lsof -c sleep COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sleep 5750 root cwd DIR 8,1 4096 8145 /root sleep 5750 root rtd DIR 8,1 4096 2 / sleep 5750 root txt REG 8,1 27880 456104 /bin/sleep sleep 5750 root mem REG 8,1 155696 301801 /lib64/ld-2.12.so sleep 5750 root mem REG 8,1 1912928 301802 /lib64/libc-2.12.so sleep 5750 root mem REG 8,1 99158752 391655 /usr/lib/locale/locale-archive sleep 5750 root 0u CHR 136,1 0t0 4 /dev/pts/1 sleep 5750 root 1u CHR 136,1 0t0 4 /dev/pts/1 sleep 5750 root 2u CHR 136,1 0t0 4 /dev/pts/1 sleep 5750 root 3u IPv4 15022 0t0 UDP *:5555 解决办法有如下几种： 1、比较死板的方法，在子进程 fork 之后关闭所有的 socket 描述符，在 execl 之前加上： int fd = 0, fdtablesize = 0; for (fd = 0, fdtablesize = getdtablesize(); fd < fdtablesize; fd++) { // close all socket handle inherited from parent process if (isfdtype(fd, S_IFSOCK)) { close(fd); } } 这种处理比较彻底，即使子进程没有 execl 也会关闭继承的 socket 句柄，如果要关闭从父进程继承的所有句柄，去掉 isfdtype 判断即可。 2、使用 fcntl 为父进程 socket 设置 O_CLOEXEC 标志，表示此 socket 在 execl 之前自动关闭（注意并非在 fork 之后），在 socket 创建完成之后加上： ret = fcntl(sock, F_GETFD); ret = fcntl(sock, F_SETFD, ret | FD_CLOEXEC); 3、Linux 2.6.27 之后创建 socket 时开始支持 SOCK_CLOEXEC 参数，与上面的效果相似，只要改创建 socket 的地方： sock = socket(AF_INET, SOCK_DGRAM | SOCK_CLOEXEC, IPPROTO_UDP); 另外 Linux 2.6.27 之后创建 socket 另外支持 SOCK_NONBLOCK 参数，如果设置此参数，socket 自动创建为非阻塞式。 以上三种办法均在 RHEL 6.1 64位系统上编译测试通过，有任何问题欢迎交流，玩的开心 ^_^
rsync在 Linux/cygwin/msys 环境下的备份性能对比
本文博客链接：https://zohead.com/archives/rsync-performance-linux-cygwin-msys/ rsync是一个开源免费的文件同步和备份工具，可用于本地备份，本地与远程服务器之间的备份，可以实现增量和差异备份，而且由于比较好的算法，在文件备份速度上也相对其它一些文件备份工具有明显的优势。 但 rsync 一直以来没有 Windows 下的原生客户端，都是基于 cygwin 环境实现，实际备份性能会受一些影响，近日看到 rsync 的 基于 MSYS 的 Win32 原生客户端已经被 port 出来，故简单做下性能对比测试。 测试环境： rsync服务器为 RHEL5 Linux 64bit，8个SATA盘的RAID0做下层存储，采用单千兆网络和千兆交换机 rsync客户端为：RHEL5 Linux 64bit，Windows 2003 Enterprise 32bit 测试时 rsync 均通过匿名方式访问，不经过SSH做用户验证，由于考虑到测试的 rsync 客户端的系统盘速度有瓶颈，客户端文件读写都通过内存文件系统来实现（Linux 上使用 tmpfs，Windows 上使用 ImDisk 模拟内存盘）。 使用同样的客户端主板分别在 Linux 和 Windows 内存中产生 1.5GB 的测试文件，然后通过 rsync 客户端进行备份到服务器（写操作）和从服务器上恢复（读操作）的操作。 备份命令示例： rsync -hv x.dat 192.168.1.125::rsync0/ 测试软件列表： 标准 Linux rsync 客户端（RHEL 5 系统自带） cygwin rsync 客户端 MSYS rsync 客户端 http://sourceforge.net/projects/mingw/files/MSYS/Extension/rsync/ RsyncWin32 客户端 http://sourceforge.net/projects/rsyncwin32/ 测试结果： 测试软件 写性能（MB/s） 读性能（MB/s） Linux rsync 105.27 105.28 cygwin rsync 76.22 64.49 MSYS rsync 7.98 8.14 RsyncWin32 76.72（出现错误） 38.50（出现错误） 从测试结果看，由于 rsync 本身面向类 Linux 环境开发，在 Linux 系统中有着非常好的性能，cygwin rsync 与 Linux 相比有一定差距，但实际使用中还是比较稳定的，而 MSYS rsync 还处于测试阶段，虽然没有出现备份错误，但在千兆网络环境下性能非常差，RsyncWin32 则相对而言问题比较多，备份过程中甚至会出现备份错误。 综上看来，目前在 Windows 上使用 cygwin rsync 做备份客户端仍然算是比较好的解决方案，MSYS rsync 的问题可以啥时候有空再看看咯。
Linux下出现 pam_get_item 的原因分析
本文博客链接：https://zohead.com/archives/linux-pam-get-item-error-library/ 近日在将一个 RHEL6 上的服务程序移植到老的 Fedora Core 2 Linux 上时出现了一些问题，该程序的功能为预先加载几个动态库，这几个动态库中再需要根据不同的需求做 PAM 用户验证操作，程序在 RHEL6 上编译和使用都没有问题，换到 Fedora Core 2 环境之后，编译时一切正常，但在运行时出现比较奇怪的 pam_get_item 错误： pam: PAM [dlerror: /lib/security/../../lib/security/pam_env.so: undefined symbol: pam_get_item] pam: PAM [dlerror: /lib/security/../../lib/security/pam_unix.so: undefined symbol: pam_get_item] pam: PAM [dlerror: /lib/security/../../lib/security/pam_succeed_if.so: undefined symbol: pam_get_item] … 程序所加载的动态库中使用的 PAM 配置文件 /etc/pam.d/system-auth 里就用到了 pam_env.so、pam_unix.so、pam_succeed_if.so 等几个 PAM 模块。 但实际系统中还有很多服务都使用 /etc/pam.d/system-auth 这个 PAM 配置来进行用户验证，都能正常工作，因此做下简单分析。 由于此服务程序太复杂，就打定写个简单的模拟程序来进行分析。 1、动态库部分（checkpam.c）： PAM 验证的实现，调用 PAM 函数进行验证，具体 PAM 函数的调用就不详细写出了。 #include <stdio.h> #include <stdlib.h> #include <string.h> #include <security/pam_appl.h> int check_pam(const char * user, const char * pass) { int ret = -1; pam_start("system-auth", user, …, …); … // 实际 PAM 代码省略，成功返回0，失败返回1 // … pam_end(…); return ret; } 和实际服务程序一致，通过 system-auth PAM 配置进行验证，编译生成动态库： cc -c checkpam.c cc -shared -fPIC -lpam -o libcheckpam.so checkpam.o ldd libcheckpam.so，查看此动态库的依赖列表： [root@linux root]# ldd libcheckpam.so linux-gate.so.1 => (0x00c67000) libpam.so.0 => /lib/libpam.so.0 (0x0025b000) libc.so.6 => /lib/tls/libc.so.6 (0x0041d000) libdl.so.2 => /lib/libdl.so.2 (0x00153000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00876000) 2、主程序部分（pamtest.c）： 加载动态库，调用 PAM 进行用户验证，比较丑陋，只需能验证，HOHO。 #include <stdio.h> #include <stdlib.h> #include <string.h> #include <dlfcn.h> int main(int argc, char ** argv) { int ret = 0; void * lpso = NULL; int (* lpfunc)(const char *, const char *) = NULL; lpso = dlopen("./libcheckpam.so", RTLD_LAZY); if (lpso == NULL) { printf("Library load failed: %s.\n", dlerror()); return 1; } lpfunc = dlsym(lpso, "check_pam"); if (lpfunc == NULL) { printf("Load symbol failed: %s.\n", dlerror()); dlclose(lpso); return 2; } ret = lpfunc(argv[1], argv[2], NULL); dlclose(lpso); printf("pam ret: %d.\n", ret); return ret; } 功能很简单，dlopen 加载刚才生成的 libcheckpam.so，然后 dlsym 找到 check_pam 函数，接着调用函数进行用户验证。 编译程序： cc -o pamtest pamtest.c -ldl ldd pamtest，查看程序的依赖列表，可以看到此时已不需要 pam 库，和实际使用的服务程序的实现方式一致了： [root@linux root]# ldd pamtest linux-gate.so.1 => (0x00631000) libdl.so.2 => /lib/libdl.so.2 (0x009ac000) libc.so.6 => /lib/tls/libc.so.6 (0x0088f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00876000) […]
Linux advisory and mandatory lock with fcntl
本文博客链接：https://zohead.com/archives/linux-fcntl-advisory-mandatory-lock/ 近日小温下APUE，发现Linux下的 fcntl 实现强制锁的功能好像都没试验过，简单做个测试。 首先用 fcntl 实现建议锁（Advisory locking），比较简单，贴个最简单的代码： 关键的几句已高亮显示，用 F_SETLKW 等待写的锁，很好测试，分别开一个终端运行一次就可以测试出来。 备注： Linux 同时实现了 POSIX 的 fcntl 锁函数，BSD 的 flock 函数，SVR4 的 lockf 函数，这些默认都是建议锁。 这个简单的实现只是建议锁，需要每个对文件的操作的进程都遵循同样的锁操作才能起作用，这些进程称为合作进程（Cooperative processes），但实际使用时会有例外的情况，如果另外开一个终端窗口直接写 test.file 文件，会发现可以直接写，因为这种写没有锁操作，不是合作进程，这种情况就需要用强制锁（Mandatory locking）了。 强制锁的实际代码和上面的完全一样，不过在 Linux 上需要做一些改动： 1、挂载文件系统时需要加 mand 参数在文件系统上启用强制锁支持，比较新的 Linux kernel 里已经基本在所有文件系统上都实现了； 2、去掉程序的组执行权限； 3、增加程序的设置组ID权限。 第二项和第三项在普通情况下实际上是自相矛盾的，所以 Linux 就用这种特殊情况就表示启用强制锁（Mandatory locking）了。 备注： 1、使用 BSD 的 flock 函数时不能使用强制锁，见 Linux kernel 源码下 mandatory-locking.txt 中的说明： Mandatory locks can only be applied via the fcntl()/lockf() locking interface - in other words the System V/POSIX interface. BSD style locks using flock() never result in a mandatory lock. 2、如果一个文件被某进程强制锁住，另一个进程通过 creat 函数或者 open 时加 O_TRUNC 参数，都会导致函数调用失败； 3、强制锁在不同的 UNIX 及 类UNIX 系统中实现不同，第二个备注中的 O_TRUNC 参数便是 Linux kernel 和 HP-UX 不同的地方； 4、tmpfs、nfs 也支持强制锁，可以用这两个文件系统方便测试； 5、删除文件（unlink操作）再重新创建文件，会导致强制锁失效； 6、Linux kernel 的强制锁的实现并不完全可靠（感觉白写了，哈哈，实际情况还要做处理），见 man fcntl 的说明。 强制锁的实际操作： mount -t tmpfs -o size=10m,mand tmpfs /mnt cp test /mnt cd /mnt chmod g-x test chmod g+s test 运行 test 程序，同时开另一个终端，直接用 echo 读写 test 文件，会发现强制锁已经起作用。