One working solution – Lua wsapi with nginx in debian/ubuntu

You need to install luarocks, nginx before followin steps, and should run as root.

1) luarocks install wsapi-xavante

Then find the wsapi command, in my installation, it is under /usr/local/bin/wsapi

it is a shell script, looks like:

https://gist.github.com/715624

2) try to create one lua folder in your nginx content folder, such as “/var/www/nginx-default/” or “/usr/local/nginx/html/”

For example, if your folder is /var/www/nginx-default/lua, change current directory to this folder, write one lua file, name is “hello.lua”:

https://gist.github.com/715632

You could find reference how to write wsapi lua in

http://keplerproject.github.com/wsapi/manual.html

3) run command: /usr/local/bin/wsapi –p 8085

Opening browser and go to http://127.0.0.1:8085/hello.lua 

You should able to see:

Hello Wsapi!

PATH_INFO: /

SCRIPT_NAME: /hello.lua

4) change nginx.conf, add following:

location ~ \.lua$ {

        proxy_pass   http://127.0.0.1:8081;

}

5) pkill lua, then run “/usr/local/bin/wsapi –p 8085 &” in folder /var/www/nginx-default/lua

Restart nginx.

6) go to http://127.0.0.1/hello.lua, it should work now.

A Fool with a Tool is still a Fool

这句话真的是太经典了,让我有冲动写篇博客赞颂一下。

http://www.dwheeler.com/flawfinder/

flawfinder是一个c/c++代码静态分析工具,类似splint,或者pclint,尽管在VisualC++找不到这个工具,其实VC++已经自带了,在企业版我们可以定义代码分析扫描规则,或者一般的版本,但你把Build Warning调到Level4,也可以看到足够的信息(如果做C++编程,没有硬性要求把Warning级别调到最高,相信我,产品质量非常值得怀疑),据我所知GCC也可以调整Warning级别,一般来说,消除了Warning提示的,代码质量可以达到50分,满分100。

我们抛开对FlawFinder这个工具的评价,只看关于这句话的解释。

Any static analysis tool, such as Flawfinder, is merely a tool. No tool can substitute for human thought! In short, "a fool with a tool is still a fool". It’s a mistake to think that analysis tools (like flawfinder) are a substitute for security training and knowledge. Developers – please read documents like my Secure Programming book so you’ll understand the vulnerabilities that the tool is trying to find! Organizations – please make sure your developers understand how to develop secure software (including learning about the common mistakes past developers have made), before having them develop software or use static analysis tools.

An example of horrific tool misuse is disabling vulnerability reports without (1) fixing the vulnerability, or (2) ensuring that it is not a vulnerability. It’s publicly known that RealNetworks did this with flawfinder; I suspect others have misused tools this way. I don’t mean to beat on RealNetworks particularly, but it’s important to apply lessons learned from others, and unlike many projects, the details of their vulnerable source code are publicly available. As noted in iDEFENSE Security Advisory 03.01.05 on RealNetworks RealPlayer (CVE-2005-0455), a security vulnerability was in this pair of lines:

 char tmp[256]; /* Flawfinder: ignore */ strcpy(tmp, pScreenSize); /* Flawfinder: ignore */

This means that flawfinder did find this vulnerability, but instead fixing it, someone added the "ignore" directive to the code so that flawfinder would stop reporting the vulnerability. But an "ignore" directive simply stops flawfinder from reporting the vulnerability – it doesn’t fix the vulnerability! The intended use of this directive is to add it once a reviewer determined that it was definitely a false positive, but in this case the tool was reporting a real vulnerability. The same thing happened again in iDefense Security Advisory 06.23.05, where the vulnerable line was:

 sprintf(pTmp, /* Flawfinder: ignore */

And a third vulnerability with the same issue was reported still later in iDefense Security Advisory 06.26.07, RealNetworks RealPlayer/HelixPlayer SMIL wallclock Stack Overflow Vulnerability, where the vulnerable line was:

 strncpy(buf, pos, len); /* Flawfinder: ignore */

This is not to say that RealNetworks is a fool or set of fools. Indeed, I believe many organizations, not just RealNetworks, have misused tools this way. My thanks to RealNetworks publicly admitting their mistake – it allows others to learn from their mistake! My specific point is that you can’t just add comments with "ignore" directives and expect that the software is suddenly more secure. Do not add "ignore" directives until you are certain that the report is a false positive.

This kind of problem can easily happen in organizations that say "run scanning tools until there are no more warnings" but don’t later review the changes that were made to eliminate the warnings. If warnings are eliminated because code is changed to eliminate vulnerabilities, that’s great! General-purpose tools scanning like flawfinder will have false positive reports, though; it’s easy to create a tool without false positives, but they’ll do that by failing to report many possible vulnerabilities (some of which will really be vulnerabilities). The obvious answer if you want a broader tool is to allow developers to examine the code, and if they can truly justify that it’s a false positive, document why it is a false positive (say in a comment near the report) and then add a "Flawfinder: ignore" directive. But you need to really justify that the report is a false positive; just adding an "ignore" directive doesn’t fix anything! Sometimes it’s easier to fix a problem that may or may not be a vulnerability, instead of ensuring that it’s a false positive – the OpenBSD developers have been doing this successfully for years, since if complicated code isn’t an exploitable vulnerability yet, a tiny change can often turn such fragile code into a vulnerability.

If you’re in an organization using a scanning tool like this, make sure you review every change caused by a vulnerability report. Every change should be either (1) truly fixed or (2) correctly and completely justified as a false positive. I think organizations should require any such justification to be in comments next to the "ignore" directive. If the justification isn’t complete, don’t mark it with an "ignore" directive. And before developers even start writing code, get them trained on how to write secure code and what the common mistakes are; this material is not typically covered in university classes or even on the job.

原文并不复杂,我在这就不翻译了。我同意作者提出的这个观点,对于傻瓜来说,再好的工具也白扯。

最近大力鼓吹推行Code Review、Unit Test,其实经常看我博客的朋友都知道,我一直在讲这句话,提升代码质量的两个关键方法就是Code Review加上单元测试,也在自己的项目中身体力行,不过由于我只是小兵一个,所以只能自己做,还打不到让其他人也跟着做的程度。对于这两个工具,没有好的执行力推动,其实是不可能达到提升软件质量的效果的。用工具,用技术,但是最关键的一点是要用对工具,而且要有持之以恒的执行。

最简单的也最容易的就是从手头的项目开始,如果编译工具可以调整Warning,调到最高,然后fix掉这些Warning。如果遇到Bug,不要Ignore,先总结Root Cause,然后写Test case,改代码,编译,跑单元测试。只要持之以恒,不需要什么CEO总经理推动,产品质量自然就提升上来了。

如果你不是傻瓜,但是你的组员是这样的傻瓜该怎么办?如果你有权力,建议你把他调开,有些人真的是不适合编程,不必强求,也许他搞销售更适合呢,让这种傻瓜捣乱的结果就是让整个开发组的士气低落;如果你没法让他离开,那就让他做一些边缘性的项目,不要碰关键代码,另外要小心盯着傻瓜添加或者修改的代码,因为一颗老鼠屎会坏了一锅汤,而且很有可能这个黑锅会被你背上。

一些技术摘选及随想

code review的目标,1)消除所有W4警告 2)给不能直接理解的代码加注释 3)丑陋代码的修改,主要针对过多for/while/if/switch这类控制的互相嵌套,把它们削平

https://bugzilla.redhat.com/show_bug.cgi?id=638477 Linus随手写了个memcpy,当然你可以在glib或者dietlibc这些标准库实现中找到工程级强度代码。

Python web server方案选择比较http://imilky.cn/blog/2010/04/python-wsgi-web-server/ 另外可以考虑http://mongrel2.org/ 现在这个新版本支持Python、Lua、Ruby、C++,uwsgi可以使用Lua开发 http://projects.unbit.it/uwsgi/wiki/Lua

如何测试webserver性能,这篇可以作为开始阅读的起点:http://en.wikipedia.org/wiki/Web_server_benchmarking 

另外很多测试提到ab,其实就是apachebench。

如何让node.js与apache/nginx共用,如何让tornadoweb与apache/nginx共用,用不着那些有的没的复杂步骤,apache用rewrite,nginx考虑proxy_pass就都完事了。

C语言正则表达式库,可以用libc里面的,也可以用pcre,oniguruma。

fastcgi可以用C写,自己devkit就有范例 http://www.fastcgi.com/devkit/examples/authorizer.c

http://hyperpolyglot.org/lisp Lisp: Common Lisp, Scheme, Clojure, Emacs Lisp lisp各式方言对比!

http://hyperpolyglot.org/scripting Scripting Languages: PHP, Perl, Python, Ruby, Smalltalk 脚本语言特性比较cheatsheet。

http://hyperpolyglot.org/small Scripting Languages: Bash, Tcl, Lua, JavaScript, Io 特性对比

http://hyperpolyglot.org/c C, C++, Objective C, Java, C#特性对比cheatsheet

C语言装逼教程推荐,http://sunxiunan.com/?p=1661 看后面书籍推荐部分,另外只需要加上一本《高效程序的奥秘》

建议Python相关讲师多使用appengine,uliweb多加入一些相关示例,appengine又易用又免费又容易部署,那些迁移成本、不能完成的任务先不考虑,用appengine做一些力所能及的东西,让其他人能实际用到,这种成就感是对初学者最好的鼓励。

最后一条推荐的新闻是Lua5.2进入rc alpha阶段,当然距离真正release也许还要不少时间,但是很值得关注!

Lua cheat sheet

lua_cheat_sheet

http://coffeeghost.net/images/lua_cheat_sheet.png

做一些简单说明。

关于所有数字都是double,在《programming in lua》第二版中有详细说明。除了极少数情况,可以满足大部分数值计算的需求。

对于table的说明比较详细。但是对于一些高阶问题没有涉及。比如协程,算是Lua的一大特色。还有函数作为first-class value,也可以做出很多有意思的东西。另外还有meta-table,是Lua模拟OO的关键。另外限于篇幅C API也没有介绍,相比其它编程语言,Lua与C的配合几乎可以说是无缝的。

相比而言,维基百科上对于Lua的介绍更为全面,而且篇幅也不长。感兴趣的可以参考这个链接作为补充 http://en.wikipedia.org/wiki/Lua_%28programming_language%29