来自BerryReview的内容。 Enrico发来消息Google升级了他的免费同步程序，原来只是可以用来同步google calendar，而现在更进化添加实现了google contacts的同步到blackberry！！！最新版本是0.5.9。 酷毙了的Google！越来越像是免费的BES功能服务了啊！现在我就期盼着google能够更加强大的整合他旗下的这些黑莓程序啦！ 安装新版本google sync（google同步），用bb浏览器访问这里m.google.com/sync

Merb 1.0已经发布。最新引入的修改包括改进对JRuby和Windows的支持等等（如JRuby下的action参数支持）。另外：EngineYard宣布对Merb的支持。 By Werner Schuster

原文作者：Heiko Webers原文链接：Ruby On Rails Security Guide ###翻译：被遗忘8.注入 — 注入这类攻击是给一个web应用引入恶意的代码或是参数，以便在其安全的上下文里运行。注入的著名的例子就是跨站点脚本（XSS）和SQL注入。 注入是非常棘手的，因为相同的代码或参数在一个环境是恶意的，但是换个环境却是完全无害的。一个上下文可以是一个脚本，查询或是程序语言，shell或是Ruby/Rails方法。 下面的章节会涵盖所有重要的注入攻击可能发生的所有上下文。 然而第一部分只涉及一个与注入相关的架构决策。 8.1. 白名单 vs 黑名单 — 当净化（sanitizing），保护（protecting）或者验证（verifying）一些东西的时候，白名单胜于黑名单。 黑名单可以是一堆恶意的e－mail地址清单，非公开的actions或者是恶意的HTML tags。 这正好和白名单相反， 白名单是安全的e－mail地址，公开的actions，合法的HTML tags等等。 虽然有时候不可能去创建一个白名单（比如在一个垃圾过滤器里），但也更应该偏向于去使用白名单的方式：: 使用 before_filter :only ⇒ […] 代替 :except ⇒ […]. 这个方法使你避免忘记去屏蔽新增的actions带来的困扰。 使用 attr_accessible 代替 attr_protected. 请看mass-assignment这节的内容（白名单） 允许<strong>而不是取消<script>来应付Cross-Site Scripting (XSS)。看下文的细节。 不要使用黑名单的方式验证用户的输入: 这是段可用的攻击代码: "<sc<script>ript>".gsub("<script>", "") 但要拒绝恶意的输入 白名单是一个好方法，可以避免在黑名单里因为人为因素而忘记一些东西的情况。 8.2. SQL注入 — 要感谢那些聪明的方法，使得在大多数的Rails应用中SQL注入成为了一个困难的问题。然而这是一个在web应用里非常严重和常见的攻击，所以理解它是重要的。 8.2.1. 引入 SQL注入攻击的目的是通过操作web应用的参数来影响数据库查询。一种常见目标的SQL注入攻击是绕开授权。另一种目标是执行数据操纵或者是读取任意数据。这有个例子来说明在查询里不使用用户输入的数据 : Project.find(:all, :conditions => "name = '#{params[:name]}'") 这段代码可能放在search action里，用户可以输入一个项目的名字来查找他想找的那个项目。 如果一个恶意用户输入了OR 1=1, 查询结果就会变成: SELECT * FROM projects WHERE name = '' ...

Hack Eye！ ( http://www.hackey... ) : 一. 简介 作为 Firefox 的插件， Tamper Data 简单易用，功能强大，可以用来查看和修改 HTTP/HTTPS 的头部和 POST 参数；可以用来跟踪 HTTP 请求和响应并记时；可以对 WEB 站点进行某些安全测试，从而为调试 WEB 配置带来了极大的便利，是网站维护人员不可多得的实用工具。 二. 安装 Tamper Data 的安装很简单，如下所示： 第一步：打开 Firefox，进入 google.cn，搜索 “tamper data”，并点击搜到的 "Tamper Data :: Firefox Add-ons-"项。如下图所示： 第二步：进入 Tamper Data 安装页面后，找到下面的位置并点击，开始安装： 第三步：安装完后后，可以在 Firefox 菜单栏的“工具”菜单项里面找到 Tamper Data，如下图所示： 三. 使用 Tamper Data 的使用也比较简单，下面介绍了其主要的用法： 点击 Firefox 菜单栏上“工具”菜单项里面的“Tamper Data”，就会弹出 Tamper Data 的主窗口，如下图所示： 可以看出，其主窗口主要分成三部分，分别如图中的 1，2，3 所示。当我们打开 Tamper Data 后，我们浏览网页时发出的每一个 HTTP 请求及其对应的响应都会被 Tamper Data 记录下来。第 1 部分显示每一个 HTTP 请求及其对应的 ...

【本文原载：Safe from the Losing Fight ，作者：Andy ，原文在此 】 最近我在研究，如何给我即将出炉的 iPhone 应用定价，并且还想计算一下这个应用一年能够给我赚多少钱。如果我只靠一个 iPhone 应用就能维持生活，而不用去找份工作，那就太完美了。不幸的是 App Store 还太年轻，没有多少历史数据可供参考。那我就把我自己能够找到的一点数据拿出来凑合凑合吧，还包括我在本文后面的评论。 要到定价的时候，绝大多数开发者都会把价格范围设置在“免费至 10 美元之间 ”。我猜这主要是因为，他们看到 App Store 里的大部分应用价格都在这个范围，所以他们就决定了。Medialets 公布了一项有趣的调查结果，App Store 里应用价格的平衡点（中间点）恰好是在 5 美元附近，尤其是游戏应用，只有那些大牌的游戏公司开发的应用才会定价 10 美元。因为苹果还要拿走 30% 的分成，所以我从每一份应用可能赚到的钱在 0.70 ～ 7.00 美元之间，也就是说，我的平均期待值应该是 3.5 美元。 既然我估计了我可能的收费价格，现在我需要知道每年合理的预期销量是多少。不幸的是，现在的数据太少了。 所以，我收集了 10 篇透露了 App Store 应用销售数据的文章。不过有些里面缺少一些背景材料，有些只是一天的销售数据，而有些则不知道销售周期（是刚刚上线还是已经上线很久的销量）。这 10 篇文章中包含的 12 个应用，受欢迎程度、宣传程度都各不相同。我在还私下获得了其他 5 个应用的数据，总结见下表： 统计中“平均每天销量”的数据，最小：1 ，最大：777，中央值：60，平均值：116 。 就像我刚开始说的，很难知道这些数据是否能够代表绝大多数应用的实际情况。但这也是我仅能找到数据了，我得靠它做点什么。 根据上面的数据，最坏的情况是：以 0.70 美元的价格，每天只能卖出一份，这意味著我一年能够赚 255.50 美元。最好的情况是：以 9.99 美元一份的价格，每天能够售出 777 份，这相当于我一年能够赚到 14.819 万美元，或者，最底限，（以 9.99 美元的价格）每天只售出一份，一年我也能够赚到 1277.5 美元。我总结的几种情况如下： （注：我在上面多次使用了“中央值”和“平均值”等数学语言，但并不代表实际发生的情况。） 我得承认，上面的平均每天销量对我来说有些高了。即使是以每天 60 个来计算吧 ，我还是决定每天 ...

默认nginx使用的GCC编译参数是-O 需要更加优化可以使用以下两个参数 –with-cc-opt=’-O3′ \ –with-cpu-opt=opteron \ 使得编译针对特定CPU以及增加GCC的优化 针对优化后的结果.我们进行测试 结果表明使用-O2以及以上的参数,可以微量增加性能1%左右. 而O2和O3基本可以认为是相同的. ./http_load -parallel 100 -seconds 10 urls 10811 fetches, 100 max parallel, 5.23252e+06 bytes, in 10 seconds 1.默认参数 -O 1087.2 fetches/sec, 526204 bytes/sec msecs/connect: 45.5374 mean, 63.984 max, 1.008 min msecs/first-response: 45.7679 mean, 64.201 max, 2.216 min 1088.9 fetches/sec, 527027 bytes/sec msecs/connect: 45.0159 mean, 65.291 max, 0.562 min msecs/first-response: 46.1236 mean, 67.397 max, 9.169 min 1102.2 fetches/sec, 533465 bytes/sec msecs/connect: 44.5593 mean, 67.649 max, 0.547 min ...

Google公开了一个测试版的谷歌拼音输入法2.0版，供大家测试，目前这个测试版已经可以下载了，我经过一些试用，发现这个版本和老版本的谷歌拼音输入法在录入上有较大的区别，并且无法保留原有的录入形式。 新的“内嵌编辑模式”，可以支持所见即所得的录入形式，这个功能的确不错，但却改变了用户的录入习惯，且无法切换回原有的录入界面，这增加了用户熟悉和习惯这一录入方式的难度，可能会让很多喜欢这个拼音输入法的用户不想升级到新版本。 在原有的谷歌拼音输入法1.0的界面中，输入中文的界面如下图所示，输入的光标处不会显示正在输入的汉字，不过在Firefox浏览器下，输入的光标处会显示正在输入的字母。 新的谷歌拼音输入法下，默认系统是打开了“使用内嵌中文编辑模式”，这时的输入界面如下图所示，输入的光标处会显示当前输入的汉字，无论IE还是Firefox都是相同的界面，但是在记事本等文本编辑器下，录入界面却和1.0的一样，没有汉字。 关闭“使用内嵌中文编辑模式”后，录入界面如下图所示，可见，实际上在录入的光标处还是有字母出现，这并没有保持传统输入体验，实际上无法实现1.0版本的输入体验。 我写博客经常就是现在记事本里写，新的谷歌拼音输入法2.0在记事本和Word中输入中文会出现不同的输入界面，这令人感到很迷惑，为什么同一个拼音输入法在不同的应用程序里会出现不同的界面和体验，这点就让用户感到有些无所适从了。 希望新的谷歌拼音输入法能够保留原有谷歌拼音输入法1.0版本的输入界面和用户体验。继续阅读《谷歌拼音输入法2.0测试版试用》的全文内容...相关文章:搜狗手机输入法发布搜狗五笔输入法发布谷歌拼音输入法再次更新腾讯QQ拼音输入法试用谷歌拼音输入法的重大算法更新

英文原版：http://envycasts.com/products/ruby-on-rails-22-package-deal 中文: http://flow.rubyn... 下载: http://files.ruby... http://www.rayfil... 水平有限，如翻译有误，欢迎指出. Email(rociiu0112#... | feipeng#sunsware.com) thanks.

Ruby's most popular Web application framework, Ruby on Rails, takes another giant step today with the release of Rails 2.2! It follows on just five months after Rails 2.1, but offers even more significant improvements, particularly in the areas of compatibility, internationalization, and documentation. Read David Heinemeier Hansson's release post for a quick overview. Ruby Inside's sister site, Rails Inside, was launched alongside Rails 2.1 in June, and would, you'd think, be the ideal place ...

同步你的黑莓和Google账户。更新了同步联系人，这样软件也已经很多了，同步这个东西，有利有弊，大家自己看着办。Google比之前的火种还是值得信任一些的吧。 Google这厮，下载地址隐藏的够深，中国移动这厮，又千般万般阻挠。 所以ota就需要用到老肥给的方法（强烈推荐）来得到了。 ota地址 4.2os 4.5os 4.6os 本地4.5os版下载不保证100%可用。 google syncVIA_ORAN.rar Tags: Google, google sync, 下载, 同步 黑莓最佳阅读体验，anyview3.2最新版下载和评测。 (0) 黑莓媒体同步软件Media Sync发布 (2) 黑莓上的Google Android 主题下载 (23) 黑莓上的Google Android 主题 (8) 黑莓4.5 os rom 正式版将在近期发布 (0)

今天收到来自sfufoet黑莓控的推荐好文《The Power User’s BlackBerry Guide: 121 CrackBerry Tips, Hacks and Resources》，中文我翻译为《极其有用的121条黑莓秘籍》，在这里和大家分享下。 翻译比较花时间，各位先看鸟文，最后中文完稿。 《极其有用的121条黑莓秘籍》 翻译整理 by 黑莓时光 - 友藏 [ 原文 ] 广大黑莓控们，你的黑莓进修之路准备好升级了吗？下面的秘籍中，你将会发现一些超强的小窍门、小常识和一些隐藏要素，让你玩转黑莓。看完它并日常用用，每个人都会成为黑莓狂人。 窍门 让你把手里黑莓用得更简单，高效和更快速。 删除多个消息：查找消息，然后在查找结果最上方选择“Delete Prior”来删除全部属于该查找结果的全部消息，比如搜索“手机报”，然后delete prior，就可以做到经常清理手机报彩信了。 阅读这个”A Wired-In Guy Getting Set for a Big Date“：如果遇到黑莓受潮甚至掉水里了，别着急，关机后将黑莓放入一碗生的大米中，让其过夜，次日基本上可能恢复正常。我身边也有朋友全身进水后，将8700放在暖气上过夜的，据说次日不仅恢复，通话效果还有明显提升。 Navigate Your Calendar Quickly: First, enable Quick Entry, then press “D” for day, “W” for week, “M” for month and “A” for agenda. Separate SMS (Short Message Service) Messages and Emails: Select Separate in the SMS and Email Inboxes ...

今天的“今日幻灯故事”是来自Fenng的“美好架构，美好未来”。 可扩展网站架构(for 网志年会) View SlideShare presentation or Upload your own. (tags: cnbloggercon webarch) Fenng是大陆blog圈中知名的技术blogger之一，他的blog名为DBA notes，主要讨论数据和网络架构，分享了许多有价值的信息和思考给业界人士。 今年的中文网志年会很幸运邀请他来现场就如何建设一个可扩展的Web网站做演讲，小容没有在现场，从大家的blog反馈来说，这次Fenng的演讲因为场地、音响和气氛的影响，效果不是很理想。 2008年的网志年会的主题朝着多元化方向去发展，技术类的演讲与往届相比在整个议程安排中显得比较少。很难评价这是好事，或是坏事。有人感叹在年会上找不到熟悉的老朋友一样。新朋友少了，老朋友多了。这是好事，还是坏事，同样难以评价。 不过，年会已经四岁了，他不再是依恋父母的婴儿了，他已经成大成为有些顽皮的小孩，对外部世界充满了好奇，开始和其他小朋友玩乐，继续尝试，继续犯错。他已经有自己的生命了。 Fenng说他今后会在其他偏向于技术主题的场合继续演讲这方面的主题。对于从事网络开发的同仁来说，能够继续聆听他的分享实在是一件幸事。 虽然说在24小时之内可以架设一个网站出来，然而，放慢一些脚步，将基础架构规划好，却是磨刀不误砍柴工。多花一些时间把基础架构部署好，是为了更好的迎接未来。 Fenng多年来一直关心这方面的话题，不仅分享了许多国外同仁关于这方面的资讯，也将自己的工作心得和体会分享给大家，在小容看来，这是社会化网络中“正业余”价值的最佳案例之一。正业余，这是小容受“专业余”这个名词的启发而发明的一个新概念，它用来描述人们在业余时间，继续通过社会化网络来分享自己的正式职业角色中的思考和体验（这也是小容对于社会化网络与职业活动两者之间的关系的思考之一，日后将会陆续分享出来）。这样的“正业余”活动，促成行业内部的专业交流，让知识得以流动，让产业从业者融合在一个没有公司边界的知识网络中。正是这样一个个投身于“正业余”活动敬业人士，他们之间的紧密联系组成了推动产业演化的实践社群，为终身学习提供了一个取之不尽用之不竭的活力源泉。 小容曾在2006年杭州的中文网志年会上有幸与Fenng见上一面。平时也一直订阅他的blog，从中学习和了解关于数据库和网络架构的知识。当然，小容并不是要转型成为一个数据库工程师：）只是，作为Web创业团队的一员，我们需要了解各个层面的基本知识，这样和团队成员沟通时，才能使用和他们相同的语言，让沟通没有障碍。 小容也顺便整理了一些自己感兴趣的贴子，做了一个Google Docs共享文件。从Fenng的blog出发，小容收集了如下的关于数据库和基础架构的资料： - 7个英文的PPT下载地址或在线观看地址； - 16篇英文的关于Web2.0网站架构分析和MySQL数据库的文章，其中包括LiveJournal，Flickr，Twitter，mixi.jp，Wikipedia，FeedBurner，Second Life，Bloglines，craigslist，Amazon，Facebook等公司的案例； - 11篇中文的关于Web2.0网站架构分析和MySQL数据库的文章。 整理这个文档的体会是，国外行业交流的气氛非常活跃，小容就自己有限的观察，对比起来，大陆blogger在行业交流上的气氛还相当淡薄，在许多行业和专业领域，尚未有许多从业者在社会化网络上展开如上所述的“正业余”活动。期待不久的将来，这样的状态会有所改变。 这个文档的TinyURL地址是：http://tinyurl.com/57mtft 小容也将这个文档共享给了Fenng，如果你也有兴趣编辑这个文档，添加更多相关资源，请在此留言，留下你的gmail地址。 Fenng也整理了一个这方面的豆列，推荐了相关的图书，请看这里：Web 2.0 网站架构不可或缺的图书 更多内容请参考Fenng的blog：http://www.dbanotes.net

今天的“今日幻灯故事”是来自Fenng的“美好架构，美好未来”。 可扩展网站架构(for 网志年会) View SlideShare presentation or Upload your own. (tags: cnbloggercon webarch) Fenng是大陆blog圈中知名的技术blogger之一，他的blog名为DBA notes，主要讨论数据和网络架构，分享了许多有价值的信息和思考给业界人士。 今年的中文网志年会很幸运邀请他来现场就如何建设一个可扩展的Web网站做演讲，小容没有在现场，从大家的blog反馈来说，这次Fenng的演讲因为场地、音响和气氛的影响，效果不是很理想。 2008年的网志年会的主题朝着多元化方向去发展，技术类的演讲与往届相比在整个议程安排中显得比较少。很难评价这是好事，或是坏事。有人感叹在年会上找不到熟悉的老朋友一样。新朋友少了，老朋友多了。这是好事，还是坏事，同样难以评价。 不过，年会已经四岁了，他不再是依恋父母的婴儿了，他已经成大成为有些顽皮的小孩，对外部世界充满了好奇，开始和其他小朋友玩乐，继续尝试，继续犯错。他已经有自己的生命了。 Fenng说他今后会在其他偏向于技术主题的场合继续演讲这方面的主题。对于从事网络开发的同仁来说，能够继续聆听他的分享实在是一件幸事。 虽然说在24小时之内可以架设一个网站出来，然而，放慢一些脚步，将基础架构规划好，却是磨刀不误砍柴工。多花一些时间把基础架构部署好，是为了更好的迎接未来。 Fenng多年来一直关心这方面的话题，不仅分享了许多国外同仁关于这方面的资讯，也将自己的工作心得和体会分享给大家，在小容看来，这是社会化网络中“正业余”价值的最佳案例之一。正业余，这是小容受“专业余”这个名词的启发而发明的一个新概念，它用来描述人们在业余时间，继续通过社会化网络来分享自己的正式职业角色中的思考和体验（这也是小容对于社会化网络与职业活动两者之间的关系的思考之一，日后将会陆续分享出来）。这样的“正业余”活动，促成行业内部的专业交流，让知识得以流动，让产业从业者融合在一个没有公司边界的知识网络中。正是这样一个个投身于“正业余”活动敬业人士，他们之间的紧密联系组成了推动产业演化的实践社群，为终身学习提供了一个取之不尽用之不竭的活力源泉。 小容曾在2006年杭州的中文网志年会上有幸与Fenng见上一面。平时也一直订阅他的blog，从中学习和了解关于数据库和网络架构的知识。当然，小容并不是要转型成为一个数据库工程师：）只是，作为Web创业团队的一员，我们需要了解各个层面的基本知识，这样和团队成员沟通时，才能使用和他们相同的语言，让沟通没有障碍。 小容也顺便整理了一些自己感兴趣的贴子，做了一个Google Docs共享文件。从Fenng的blog出发，小容收集了如下的关于数据库和基础架构的资料： - 7个英文的PPT下载地址或在线观看地址； - 16篇英文的关于Web2.0网站架构分析和MySQL数据库的文章，其中包括LiveJournal，Flickr，Twitter，mixi.jp，Wikipedia，FeedBurner，Second Life，Bloglines，craigslist，Amazon，Facebook等公司的案例； - 11篇中文的关于Web2.0网站架构分析和MySQL数据库的文章。 整理这个文档的体会是，国外行业交流的气氛非常活跃，小容就自己有限的观察，对比起来，大陆blogger在行业交流上的气氛还相当淡薄，在许多行业和专业领域，尚未有许多从业者在社会化网络上展开如上所述的“正业余”活动。期待不久的将来，这样的状态会有所改变。 这个文档的TinyURL地址是：http://tinyurl.com/57mtft 小容也将这个文档共享给了Fenng，如果你也有兴趣编辑这个文档，添加更多相关资源，请在此留言，留下你的gmail地址。 考虑读者打不开Google Docs文档，现在小容将这个文档的内容全文贴在下面： 参考资料： Part 1: English PPT： 1. LiveJournal’s Backend: A history of scaling (PDF) http://www.danga.... 2. Capacity Planning for LAMP MySQL Conf 2007 (PPT) John Allspaw, Engineering Ops Manager, Flickr.com http://www.scribd... 3. Twitter: A Small Talk on Getting Big (PPT) ...

[文章作者：张宴 本文版本：v1.0 最后修改：2008.11.19 转载请注明原文链接：http://blog.s135.com/post/379.htm] 在生产应用中，某台“Nginx+PHP+MySQL”接口数据服务器，扮演的角色十分重要，如果服务器硬件或Nginx、MySQL发生故障，而短时间内无法恢复，后果将非常严重。为了避免单点故障，我设计了此套方案，编写了failover.sh脚本，实现了双机互备、全自动切换，故障转移时间只需几十秒。 一、双机互备、全自动切换方案： 1、拓扑图： 2、解释： (1)、假设外网域名blog.s135.com解析到外网虚拟IP 72.249.146.214上，内网hosts设置db10对应内网虚拟IP 192.168.146.214 (2)、默认情况下，由主机绑定内、外网虚拟IP，备机作为备份，当主机的MySQL、Nginx或服务器出现故障无法访问时，备机会自动接管内、外网虚拟IP。两台服务器都启动负责监控、自动切换虚拟IP的守护进程/usr/bin/nohup /bin/sh /usr/local/webserver/failover/failover.sh 2>&1 > /dev/null & (3)、主机和备机上的MySQL服务器互为主从，互相同步。在主机处于活动状态（即由主机绑定虚拟IP）时，读写主机的MySQL，写到主机的数据会同步到备机；在备机处于活动状态时，读写备机的MySQL，写到备机的数据会同步到主机（如果主机上的MySQL死掉暂时无法同步，主机上的MySQL恢复后，数据会自动从备机上同步过来，反之亦然）。 (4)、主机处于活动状态时，每20秒会把/data0/htdocs/（网页、程序、图片存放目录）、/usr/local/webserver/php/etc/（php.ini等配置文件目录）、/usr/local/webserver/nginx/conf/（Nginx配置文件目录）三个目录下的文件通过rsync推送到备机服务器上的对应目录（增量推送，两台服务器上一样的文件不会重复推送），反之如果备机处于活动状态时，每20秒会尝试把文件推送到主机。rsync的配置文件见两台服务器的/etc/rsyncd.conf，rsync守护进程的启动命令为rsync --daemon 3、自动切换流程 (1)、主机默认绑定内、外网虚拟IP，当主机的MySQL、Nginx无法访问或服务器宕机，主机上的failover.sh守护进程会自动摘除自己绑定的内、外网虚拟IP（如果主机上的failover.sh死掉，无法摘除自己绑定的虚拟IP也没关系），备机上的failover.sh守护进程会自动接管备机原来绑定的内、外网虚拟IP，并发送ARPing包给内、外网网关更新MAC，强行接管。 (2)、备机绑定虚拟IP后，会发送ARPing包给内、外网网关，通知网关更新虚拟IP的MAC地址为备机的MAC地址，从而保证了切换后能够通过虚拟IP及时访问到备机。 (3)、如果主机的MySQL、Nginx启动起来，全部恢复正常访问，主机上的failover.sh守护进程会检测主机上的MySQL数据是否已经完全从备机上同步过来。如果同步延迟时间为0，主机会自动接管内、外网虚拟IP，并发送ARPing包给内、外网网关，而备机也会自动摘除内、外网虚拟IP。 (4)、整个切换流程均由failover.sh自动完成，无需人工处理。 4、注意事项（很重要）： (1)、crontab里的文件没有做自动同步，如果修改，需要手工在两台服务器上都做修改。 (2)、/data0/htdocs/目录内任何用ln -s建立的软连接，rsync不会自动同步，如果在一台服务器上建了软连接，需要手工在另外一台服务器上也建相同的软连接。 (3)、如果要删除/data0/htdocs/目录内的某些文件或目录，需要先删除处于活动状态（即绑定了虚拟IP）服务器上的文件或目录，再删除处于备用状态服务器上的文件或目录。 (4)、除了/data0/htdocs/（网页、程序、图片存放目录）、/usr/local/webserver/php/etc/（php.ini等配置文件目录）、/usr/local/webserver/nginx/conf/（Nginx配置文件目录）三个目录之外的其他配置修改，需要在两台服务器上都做修改。 二、配置文档与脚本： 1、主机、备机两台服务器的rsync配置（配置相同） (1)、rsync配置文件vi /etc/rsyncd.conf 输入一些内容并保存：引用uid = rootgid = rootuse chroot = nomax connections = 20pid file = /var/run/rsyncd.pidlock file = /var/run/rsync.locklog file = /var/log/rsyncd.log[data0_htdocs]path = /data0/htdocs/ignore errorsread only = nohosts allow = 192.168.146.0/24hosts deny = 0.0.0.0/32[php_etc]path = /usr/local/webserver/php/etc/ignore errorsread only = nohosts allow ...

Testing is a firmly ingrained part of the Ruby culture: you probably ran across Test::Unit not long after you first started writing Ruby code (though it wouldn't be surprising if you ignored it for a while). But it hasn't been a static part of Ruby - we've seen the simple availability of tests evolve into test-driven development (TDD) that in turn gave rise to behavior-driven development (BDD). Along the way, Ruby has spawned a variety ...

摘要：前些时候刺写过一个关于当前WEB架构中session和cookie安全问题的文章《Restful风格架构下的一个容易被忽视的安全隐患》，我和他在 公司讨论时提出过解决方案，他在文章也中有提到。在文章后面的评论里，我也有和其它人做过一些探讨。今天闲一点，大致稍微详细一点说说目前流行的这种WEB系统安全架构需 要注意的问题。 前些时候刺写过一个关于当前WEB架构中session和cookie安全问题的文章《Restful风格架构下的一个容易被忽视的安全隐患》，我和他在公司讨论时提出过解决方案，他在文章也中有提到，文章的后面的评论里也有和其它人做过一些探讨。今天闲一点，大致说说目前流行的这种WEB系统安全架构需要注意的问题。 顺便先提一下所谓当前流行的WEB架构。在网络架构方面，目前流行的趋势和以前传统的门户网站采用七层交换，或者四层交换集中式部署做负载均衡不同，比较倾向于在物理位置上做分布式节点，通过智能DNS引导用户就近访问。这些CDN节点，有的是实际的WEB服务器，但是大多数可能只是一些Squid或者 Nginx之类的反向代理。这样做的好处第一是有更好的用户体验，第二是在拒绝服务攻击时，也有更灵活的应对方式。 鉴于系统分布式部署的趋势，因此在编码方面，也就开始流行刺提到过的Restful风格。所谓Restful风格，本质来说，就是客户端自己维持自己的状态，而且服务端信任这个客户端维持的状态。根据从客户端获取到的不同的状态，返回不同的页面。这里尽量的减少了服务端的判断等工作，让客户端对WEB系统的依赖性减轻，服务端做的仅仅是根据状态返回结果，并且在需要时为服务器设置一个新的状态，即所谓状态变迁。这点和P2P的去中心化有些类似，客户端不太在意自己连接到了哪一个服务器上面，只要自己维持着自己的状态，连接到WEB系统的任意一个服务器得到的结果都是一样的。目前流行的做法，就是不适用 session仅仅使用cookie，当然使用数据库session也是可以的。但是我觉得尽量把这些事情给客户端去做更好，减少数据库服务器的维护成本和故障风险，去中心化彻底一些。 目前这种分布式缓存节点大量使用，以及客户端自己维持状态的架构的流行，带来的两个安全风险就是敏感内容缓存的风险，以及客户端状态窃取或伪造的风险，而且前所未有的突出。 关于客户端维护的状态检验以及反窃取，关键点在于对cookie的加密算法强度以及完整性检验可靠度。在客户端状态被窃取时降低风险，我提到过cookie加入时间戳的方案，这个在刺的文章里有很详细的探讨，包后后面很多评论。 关于用户退出以及反窃取这里，再提一点。使用Session的方案，用户退出时在服务端销毁Session即可。即使有人盗取了cookie，使用 cookie里面保存的sessionid做刷新也是无效的，因为session实体已经在服务器上不存在了。新的无session方案中，这方面实现起来会麻烦一些。我的看法是，需要一个数据库记录用户的注销状态。当用户退出时，清空用户的cookie，同时在数据库中写入该用户已经登陆，下次不再使用 cookie认证，强制要求输入密码登陆。这样解决了cookie被盗取但是没超时的情况下，用户退出被盗取的cookie也不失效的问题。可惜的是这样又加上了一个数据库，那么结合起来看，把Session存入一个集中的数据库，在部署上并不比单纯的使用cookie差多少。 敏感内容缓存风险，主要是指用户A访问CDN上某个节点的时候，查看了一些包含自身信息在内的页面，而WEB系统在缓存方面没有做到足够的安全性，可能会导致这些敏感信息被用户B无意中看到。虽然缓存服务器可能不会缓存这些内容，但是随着缓存接点的急剧扩张，小几率的问题也会逐渐放大。就这个问题而言，可以在缓存服务器和代码两个点中的任意一个采取措施。虽然可以通过配置代理服务器策略保证安全，但是一般来说，防御应该是多层的，立体的，必须在代码中对缓存作出明确的控制。因为对于安全来说，需要尽可能的在不安全的环境中的保证系统的安全。代码中不做安全控制，这次部署的缓存系统是安全的，下次部署的缓存系统则可能出现疏忽。更何况，其他第三方无法控制的缓存服务器。 WEB系统中对缓存的控制，在RFC2616中14.9节有详细的描述。主要有public，private，no-cache，no-store等选项，具体描述可以仔细阅读RFC文档。值得一说的是no-cache和no-store的区别，no-store是比no-cache更严格的控制，按照 RFC原文：Even when this directive is associated with a response, users might explicitly store such a response outside of the caching system (e.g., with a "Save As" dialog). 总的来说，这种流行的架构看重分布式部署，和客户端状态维持，因此在架构中，更需要考虑缓存的安全以及客户端cookie的安全。在编码之初，就要关注到这些问题，到后期再改，就会来不及了。

I gave a talk today at the #prorubyconf on Ruby Deployment, past present and future. You can view my slides below. We will start doing some private beta testing of our new EY platform in December so let me know if you want to beta test and havce some interesting apps to run in the cloud. Ruby DeploymentView SlideShare presentation or Upload your own. (tags: cloud engineyard)

In which I show that XML does not have to suck—instead you can just HappyMap it! As much as I write about XML, you would swear it is all I do, but I promise it is not. In fact, I do not really use XML that often, but I will admit that I am intrigued by it. A while back, you may remember, I posted about ROXML, a ruby object to xml mapping library. I ...

http://www.infoq.... rails2.2 的特色之一就是conditional GET 判断的依据是http headers: last_modified and etag Rack::Cache 依据到期更新和验证两种手段来完成HTTP caching produce freshness (Expires, Cache-Control) and/or validation (Last-Modified, ETag) http://tomayko.co... http://tomayko.co... http://chinaonrai...