引言：

     近几年来是一个创客的时代，我们每天都能在各种不同的地方看到不同的人在各种不同的产品，国内已形成一种创业的热潮。媒体捧吹，政府政策支持，这年头不说自己是创业者都不好意思创业。就拿北京来说，不知道一天内有多少家创业公司兴起，有多少家创业公司倒闭。

    从2011年开始，大数据逐渐进入互联网热词行列。2012年美国硅谷投资的最热门主题就是大数据，大数据的时代的到来也造就了不少创业公司。国外的比如，大数据业务分析公司Splunk、数据服务公司Metamarkets、数据可视化公司Tableau、大数据分析公司ParAccel等。当大数据这个热词涌入国内的时候也促进国内的互联网巨头们也在纷纷布局切分蛋糕，比如阿里、百度、腾讯、金山，还有在线教育的小象学院和早期成立的数据分析专业社区炼数成金。

    进入到2013年莫过于最火的就是云计算和虚拟化技术，作为技术人员熟悉的kvm，vm，esi，cloudstack，openstack等，逐渐进入到互联网技术人员的视野。其中也不乏不少创业者看到了方向。比如基于openstack技术成立于2013年的OpenStack开源云计算公司UnitedStack，还有基于基于cloudstack市场的天云趋势等。

    2014年大家听得最多的莫过于devops和Iass这两个词语吧。devops让我们的运维同学从脚本时代走进了coding时代，因为现在越来越多的公司都要求你会python或者其他的语言，不只简简单单的会个shell脚本就行了，因为互联网在进步。从云的概念进入中国市场，越来越多的创业者看到了中国这个行业的大市场，在国内做Iass服务的，有我们熟知的阿里云，腾讯云，ucloud，青云等。

    从2014年下半年到2015年互联网创客，熟知的应该就是基于Docker容器技术的创业者们，比如DAOCLOUD，云雀，数人科技，希云，Tenxcloud等，同样APM这个词也逐渐成为创客们中的热词了，在国外有我们熟知的APM的创业公司比如：Compuware、iMaster、New Relic、AppDynamics等，而国内的创业者们也看到了中国这个大市场，大蛋糕，也不乏创业公司比如：云智慧、OneAPM、听云等。

  APM是什么鬼   

    应用性能管理（Application Performance Management）是一个比较新的网络管理方向，主要指对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本(TCO)。使用全业务链的敏捷APM监控，可使一个企业的关键业务应用的性能更强大，可以提高竞争力，并取得商业成功，因此，加强应用性能管理（APM）可以产生巨大商业利益。

              如果你还不了解APM是什么东东，请你移驾这里一张图告诉你什么是APM，想知道什么是真正的APM看这里。

AMP见闻之云智慧
              2015的ArchSummit架构师大会可谓是空前盛况，有将近近千名的架构师们参加。不乏百度、AWS、小米、华为、腾讯等大公司的架构师参加，也有Ucloud、青云、DAOCLOUD、云智慧等新型创业公司的加盟。
 
              作为一个运维人员我可能最关心的就是我们线上的架构应该怎么部署合理和现有架构的性能在哪里的问题，所以我这次特别关心了一下APM主题的演讲，所以在这里我为大家介绍一下我在大会看到的云智慧 高级架构师 高驰涛(Neeke)演讲的"APM与高性能架构"
 
              首先我先介绍一下他在PPT中展示演讲的三个点:性能瓶颈----->瓶颈是谁----->怎么解决 ，那下面我就逐一介绍。
 
性能瓶颈
      1.用户体验            

               不管是一个网站、产品、衣服，用户体验是很重要的，因为只有公司的产品有了用户，这家公司才有前景，才有收益。我之前一个同学在小米的应用推广平台做运维，有一天他跟我说，他们今天平台的日流水要破千万了，可想而知，一个产品只有用户才是你最大的支柱，只有用户体验好了，才能留住用户，你的产品才能体现出更高的价值。所以雷军说过要把产品做到极致，而这个极致的背后就是用户体验。
 
               而用户体验的改善我们需要去从不同的角度去分析，就如上图所示的一样，从设计方面，我们设计出更符合现在用户更喜欢的UI的风格界面，从服务方面，我们需要做好技术售后的服务和海底捞式的优服务，从产品方面我们要把产品做到极致，从性能方面，我们要让用户体验的更爽，让他的抱怨更少，从架构方面，我们应该拿出GEEK的精神去部署，从交互方面，我们应该做到简约明了，而这些并不是每个公司都能做到的，我们可以通过第三方的SaaS提供商来解决这些，可以促进我们更快、更高效的解决这些问题，当这些问题不存在了，作为工程师的我们就可以坐到办公室里面喝茶了，而不是天天焦急频繁迭代去改善我们产品的这些问题，当然这是一个最理想的状态，我想不久的将来会是这么一个状态，因为我们就在做这件事。
      2.网站架构模型


                 作为技术人员我们都知道网站的典型架构模型如上所示，随着业务增长，架构也会越来越大，关系的方面很多有网站的高可用性、数据的一致性、数据存储和搜索等等一系列的问题。随着这些问题的不断产生、扩张，你觉得作为技术人员的你，还有时间喝茶吗，公司只会不停的去招人，不停的去解决这些问题，从而导致你的网站、产品的质量和体验值都会下降，所以应用系统性能对用户的体验是至关重要的！
      3.应用系统性能

                 说起流氓这个词，我想流氓会武术，谁都挡不住哦。但是在这个创客的时代，创业者们本来就是"流氓"，因为创业就是这样的，你成功了你就是预言家，失败了你就是在催牛逼。

                 前不久淘宝、携程相继出现故障，我想对他们自己的业务带来了不小的影响，淘宝还好，我相信淘宝确时是因为光缆破坏导致的故障，可怜的是携程，整个业务故障时间整整有半天之久，这个对用户的体验是非常不好的。也会造成用户对公司的信任，我的个人信息是不是会被暴露等一些问题，所以说应用的性能确实很重要，直接影响到了公司财政收入啊。难怪携程故障，老板会发出话来说，谁能给我最快的速度解决问题，奖励100万呢！

瓶颈是谁
        1.环境分析

                 一个公司由不同的部门组成，又我们的技术客服、运维、开发、市场等组成。作为一个互联网公司，当公司发展的道路上，遇到了阻力，我们产品的应用性能问题，到底是谁负责，谁来解决呢？通常我们一般都会先想到我们可爱的开发者同学们身上，然后我们开发的同学就不停的加班，解决bug和问题，但是最后效果并不是很好。就如下图所示：

                 那就让我们来分析分析应用的环境吧

                 没错，如上图所示应用就是一个多技术栈复合的整合环境。我想大家看到这么一个细化的环境，你让我们可爱的开发同学，怎么去发现问题点，即使花了大部分时间找出的问题所在，这么一个环境一个人可能完成吗，需要多个开发同学配合修复，但是等你花了大部分时间来分析你应用的时候，你公司的业务进度也是停滞不前的，蛋糕也许就被别人切走了！所以这就是APM的价值所在，透视宝则孕育而生


       2.坑在哪里


                   问题出现了，作为技术人员就会去找坑，但是业务环境和系统环境都可能有问题，所以找坑成为一种苦恼，喝茶的时间自然没有，我们需要从前端cdn层、web层、缓存存、数据层等方面着手一一去分析，但是最后你不一定可以准确的找到答案。就拿我们线上一次事件来说吧，我们的业务任务调度出现了瓶颈，我们足足花了三天之久的时间，最后才有80%的把握确认瓶颈出现在缓存系统redis上面，虽然已经找到了问题所在，最后重启redis，把资源释放了，最后暂时把问题解决了，但是最后这种问题还是会发生了，所以最后我们只好扩展redis，最后选择用来豌豆荚开源出来的分布式redis系统codis得于解决。从这个案例上来看，可想而知，查找坑是多嘛痛苦的事情啊，这让我想起了一句歌词"多么痛的领悟"! 而APM正好可以帮你解决你的痛苦。
 
怎么解决
                     那我们到底应该怎么去发现和解决呢？
       1.优化方案

                      我们的分享人给出了如上图所示的一些建议。无可厚非，我们在设计架构和语言程序的选择上面，头期一定要多考虑到性能问题和可扩展和高可用的问题，要不后期随着产品和业务的增长你只能去找坑，填坑了！


                      对于监控大家当然不陌生，监控是作为一个业务增长保证的基础，因为在业务增长的同时，我们要未雨绸缪的考虑到一些性能方面的问题，而监控正好可以我们很好的做个预警工作，可以让我们有足够充裕的时间来解决问题，不至于等到问题出现，来临时抱佛脚，着急的处理。而云智慧他们有这个优势，因为他们还有一款产品监控宝, 我想大家应该都听说过吧。
     
        2.发现解决

                       如上图是云智慧产品透视宝的Smart Agent的架构图，那它的特点是什么，能干什么?

                       从上图可以看出smart agent就是类似于我们常说的一个嵌入的sdk一样，只不过这是一个比较高级的sdk，它可以自动发现你主机上面的应用程序、代码执行效率、已经整个环境的生态关系和性能指标的采集、分析数据，从而发现你这个应用系统的性能瓶颈所在。那有人，就会问了这个东西安装在我服务器上是否安全，我的信息是否会被盗取和丢失呢？

                         我想作为用户有担心是无可厚非的，但是我想做一个长久的公司，是会考虑到我们用户的感受的，看到如上图的解释，我想安全问题，应该不存在的。那这个系统实现原理是怎么样的，是怎么实现的？大会上分享人给出了一个php code执行的数据流图

                          整个系统又能解决哪些问题呢？

                          web端用户体验问题


                          作为运维工程师，经常会有客户反应公司网站慢，但是作为运维人员有不能很好的去查询预知，哪个地方的客户访问比较慢，只有客户反应过来才了解，这样就导致用户体验不好的问题，以致业务收到影响。我这里举个例子，我上家公司是做app市场推广和下载的，类似于91助手，我们公司的用户群体主要集中在北京、上海、深圳、广州等一线城市，有一天我们领导要我分别去测试评估这几个城市在我们平台用户下载速度，这可是给我出了一道难题了，我只好让朋友帮忙，测试了，然后评估一个数据了。页面详情追踪我想，为我们做web优化做出了很好的分析，可以针对相应慢的资源，做出相应的优化方案，不错觉得功能还可以，可以解决痛点！
                         后端服务事务分析


                         深入到后端可以让我们清晰的了解性能出现在哪个节点上面，代码级别可以让我们深入了解开发者的代码性能的问题，已经查询SQL性能的问题。看起来挺好高级的，但是如果能提供解决方案更好了。比如查询出来我有一个SQL执行时间过长，然后给出一个认为更优的SQL语句，来做到真正为用户考虑，尽最大力度，减小用户的痛点，就更好了，不过作为创业公司已经做的很不错了，继续加油吧！
                          应用架构

                          有一个清晰的业务应用架构，当然对解决问题是有很大帮助的。最后问题发现了，解决了，是不是可以喝茶了，balabala，happy！


                           真心要喝茶去了，因为大牛的分享结束了，真是意犹未尽啊！
下面我分享几张现场的照片和大牛的PPT给大家
PPT下载地址

本人文笔有限，欢迎大家交流、拍砖

先吐槽下qq群的调查功能，先后搞了2次调查，都没有了，数据消失了。难道qq调查的理念是，玩“闪调”，调查完就消失？

说下调查结果
OpenStack

从调查结果看，OpenStack无疑是王者，前几天刚过了5岁生日，已经5岁了，但是还没有成熟，依旧活力四射。有人说OpenStack就是一个框架，一个协议族，就像网络的TCP/IP模型，真正要实施还要靠自己。

大家形成的共识是，玩OpenStack没有一定规模的开发团队搞不定，对中小型企业来说，要使用OpenStack，买一个有支持的发行版也是一个思路。

OpenStack 评级 持有 还会继续升值
 
Cloudstack OpenNebula

Cloudstack OpenNebula 这一年来，明显社区活跃度在下降，尤其是思杰投入到OpenStack阵营，更是对Cloudstack的打击，如果一直在使用这两个平台，可以继续使用，如果没有使用过，这两个平台建议就不要选择了。

Cloudstack OpenNebula 评级 出售 升值空间已经不大了
 
oVirt/RHEV

oVirt/RHEV 更适合中小型企业使用，设计目标也是中小型企业的管理工具，从个人测试的结果看，也是大问题没有，小问题不断，而且更新频繁，经常造成安装都是问题，要稳定使用还需要打磨。

oVirt/RHEV 评级 持有 还会继续升值
 
ZStack

ZStack 是国人开发的开源管理软件，脱胎于Cloudstack，许多理念和Cloudstack一样，但是比Cloudstack部署、使用方便很多，现在版本迭代非常快，很快要推出中文版了。

ZStack 评级 关注 还会继续升值，建议考虑在1.0的时候买入
 
WebVirtMgr

WebVirtMgr 是一个纯Python写的管理工具，前端和后端都是Python，是Python用户者的最爱，许多Python爱好者都对WebVirtMgr做了二次定制，目前主要的问题是功能太少。

WebVirtMgr 评级 关注 又可能继续升值，建议考虑在成熟的时候买入
 
Virtsh+VirtManager

Virtsh+VirtManager 是老牌绩优股，是每个人必备的工具，这个就不多说了。

Virtsh+VirtManager 评级 持有 长期稳定升值
 
自己研发

自己研发也是一个思路，底层的Libvirt已经非常完善了，完全可以在这个基础上，根据自己需求，开发一个非常简单的，适合自己的平台就ok。

自己研发 评级 持有 会持续升值
 
热爱虚拟化技术的同学，可以扫描二维码，订阅哦！

原文地址

/bin/bash^M: bad interpreter: No such file or directory

出现上面错误的原因之一是脚本文件是DOS格式的, 即每一行的行尾以\r\n来标识, 使用vim编辑器打开脚本, 运行:

:set ff?

可以看到DOS或UNIX的字样. 使用set ff=unix把它强制为unix格式的, 然后存盘退出, 即可.

 
 
 
 

今天查看微信订阅号，查看到了微信订阅号"运维帮"南非蜘蛛发布的一篇文章"纪念曾经一起上过的技术社区",文章最后的一句话明显是重点，前面说的都是铺垫，这么做的原因是什么，请看我的分析。
"纪念曾经一起上过的技术社区"文章原文如下： 

       不知道是现在技术太成熟，还是大家都懒的交流，以前活跃的社区都歇菜了，比如Chinaunix、ITPUB、Linuxfans、Linuxform、Linuxeden、网易社区等等。

作为国内最大的技术社区Chinaunix，今天的数据统计是：

论坛共有 17794083 篇帖子(其中 1459640 篇主题) 今日发帖量为 139 篇 

现在每天发帖量也不过200篇，都已经杂草丛生，无人管理，版主会议室也是常年无人发言，经常看到很多版主请辞，估计是不做这行了？也可能是精力不够。

社区之死是什么原因？无人知晓。

我个人还是比较喜欢bbs和邮件订阅形式的技术讨论，一是讨论的东西可以沉淀，留下历史记录，如果搜索引擎收录了，还可以帮助更多的人，二是想回答就回答，不想回答就潜水。QQ和微信讨论的好处是实时，但坏处也是实时，天天被人追着问问题，我心也不免狂躁，就算不回答，看着头像闪来闪去也闹心。

现在还有一些其它地方也可以讨论技术，反正只要有工程师活跃的地方，就有技术讨论。

微博讨论技术感觉是怪怪的，好像更适合发布一些消息，而且噪音太多，有用的东西很容易被淹没在明星的爆料中，微博娱乐属性更强一些，其次是科技新闻。

知乎这种问答社区也经常看到技术讨论，但是更多的是争吵和鄙视。



寻找一方净土，一起学习技术，看来只有yunweibang订阅号了，还有运维帮线下技术沙龙，准备开始第二期了，大家一起期待一下。

     上面的内容中有我共鸣的地方那就是，有好的东西，好的技术文章和好的解决方法我们应该分享出来，被搜索引擎收录，然后帮助跟我们一样，学习linux开源技术和编程语言等技术的后来者，可以让他们走很多弯路，减少痛苦，这何乐而不为呢？我相信就行开源的一些技术一样，如果它不开源出来，源代码不开放，你根本就不会了解到它核心的思想，和优秀的地方，也不会促进大家一起共享代码，共同推动技术的发展。

       确实现在好多技术社区已经不活跃了，基本上就是搜索引擎搜索到一些旧的文章和问题，带来这些社区的一些访问。我想原因有如下几点：
       1.现在很多做技术的人都有自己的博客了，所以他们主动逛这种社区类型的网站概率小了。
        2.就是现在主流做技术的人员比较活跃的人群的年龄阶段已经是80后到93之间的群体了，而这些人都是比较喜欢新鲜事物和追求一些geek精神的人，以前的站点旧式的bbs的页面，已经不能让这些人很好的接受了，因为这些界面拿现在来说，就是落后式，就是比较loss。
        3.现在的技术者平常很少关系站点的好坏和分享的问题，因为现在互联网信息传播的途径太多了QQ，微信，Qzone，微博，社区等。他们不该如何选择了，所以他们干脆就不选择了，随波逐流，看到好的技术文章和分享就赞和分享，所以导致技术者们没有专一的习惯了，所以以前的一些技术社区都在衰败中了。

        "南非蜘蛛"在文中还提到了知乎，以说知乎我其实不得不吐槽一下。恨一个人肯定是有原因的，要不是以前太爱了被伤害了，要不就是被虐待了，当然我吐槽知乎也是有历史原因的。当初我也是发现像"南非蚂蚁"所说的问题，就是大家纯分享技术的动力越来越少了，变成了聊天，侃大山不管是qq群还是微信群，真正做技术分享和帮助的社区网站太少了。所以当初我就拿着我朋友"采菊篱下"的openskill.cn这个域名到知乎提问，问题的内容是"大家好，我和我朋友有个域名openskill.cn，然后希望做一个技术分享的社区，让大家可以看到有货的一个社区，做一个分享的社区，希望有愿意和我们一起弄的同学，联系qq：912xxxx" ,但是后来知乎就给我发来一封私信"说我发的信息是广告等垃圾信息" ，后来我就无意间回了一封私信"你们公司 什么意思啊 我这个提问 认为是广告等垃圾信息，我违反什么了?",但是没有下文了，到最后也就这样了。这就是我吐槽知乎的原因。所以以后我再也不上知乎，也不看知乎里面的信息，当然就像"南非蜘蛛"提到的"知乎这种问答社区也经常看到技术讨论，但是更多的是争吵和鄙视",因为知乎现在的运营已经形成了这种恶劣的情况，谁是什么ceo，什么cto，高级dba，高级什么莫莫。这不是一个技术分享社区应该有的现象，这就是知乎自认为所谓的价值存在的地方，你看我们网站这么多人用，有谁，这个那个，cto，ceo，什么的，把分享和开源的精神都扭曲了，所以我不喜欢知乎。经过知乎这件事情后我和我朋友"采菊篱下"就一起创建了现在这个技术文章分享和工作中遇到的错误和技术难题解决方法和思路的一个，技术问答和文章分享的网站AfewBug 分享动力。虽然现在没有什么用户和跟我们有共同爱好的人来做这件事情，但是我们会坚持的，因为我们是爱分享和爱开源的人。希望可以帮助到后来者，我们发布的这些文章和错误的解决方法和方案！

       最后我们回到话题"寻找一方净土，一起学习技术，看来只有yunweibang订阅号了，还有运维帮线下技术沙龙，准备开始第二期了，大家一起期待一下。"南非蜘蛛同学明显实在为自己的订阅号，做广告和宣传吗，我不想深入说其中的缘由，都在互联网我想大家都应该知道。但是我希望大家做的事情都是正能量，可以让大家受益的，而不是极少数的人受益。

        当然我写这篇文章有人也会说，你是不是也在做广告和拉用户量，然后让你们网站火起来啊。我想说的是，不是，但是相不相信就看你自己心里怎么判断了。因为我写这篇文章的目的是想告诉大家，真正好的东西，应该大家一起分享。还有就是我个人认为微信真心不是学习技术的一份净土，它可能是很好的营销和市场宣传的一个很好的渠道和途径。因为现在微信已经是很多公司、微商、自媒体、网站等，传播知名度的一个很好的工具。无可厚非，微信并没有错，它是成功的，正是因为它的作用它才有存在的价值。所以南非蜘蛛写净土只有yunweibang订阅号了，他并没有说错，因为这是微信的作用。

        这篇文章纯属自己心血来潮，都是个人观点，不过欢迎大家拍砖。

本周初，OpenSSL发布了CVE-2015-1793的漏洞更新包:

这些更新包在7月9日发布，它们将用于修复一个“高危漏洞”。这些漏洞不会影响1.0.0或者 0.9.8版本。--->Forthcoming OpenSSL releases

漏洞细节及修补补丁的具体方法将在下面给出：

高危漏洞补丁

该补丁修复了一个高危漏洞。由OpenSSL团队出版，详情如下:
在证书验证期间，OpenSSL(1.0.1n到1.0.2b版本)将试图寻找一个证书验证链，如果没有找到，那么OpenSSL又会试图寻找另一个证书验证链。但是在这个逻辑的实现中却存在着一个错误，这个错误将导致攻击者可以使用不受信任的征收绕过检查。比如 CA 标识。这使他们能够使用无效的证书充当证书验证链中的叶子证书，比如 CA 和 "issue"。 
----->OpenSSL Security Advisory [9 Jul 2015]

这种漏洞允许黑客进行“中间人”攻击，并且能让程序在看到无效和不受信任的证书时让应用程序把该无效证书当成有效的。基本上，它可以让没个人都能成为他们自己的证书颁发机构(Certificate Authority.CA)。

这个Bug已被提交到： aae41f8c54257d9fa6904d3a9aa09c5db6cefd0d.

还提交到了:2aacec8f4a5ba1b365620a7b17fcce311ada93ad.

该问题确实相当严重，这意味着又它又被修复了一次。

不幸中的万幸是，它只有限地影响部分OpenSSL版本：OpenSSL 1.0.2c，1.0.2b,1.0.1n ,1.0.1o。

受影响的版本和操作系统有哪些？

该漏洞似乎只存在于OpenSSL在2015年6月以后发布的版本中。这貌似让如Linux这一类的系统相对比较安全。因为他们已经有很久没有更新OpenSSL了。

Red Hat，CentOS和Ubuntu完全不会受此漏洞影响，因为在2015年6月没有发布针对这几个系统的版本。

正如Red Hat宣布的：

OpenSSL项目已发布一个重要漏洞补丁（CVE-2015-1793）,该漏洞影响OpenSSL的1.0.1n,1.0.1o,1.0.2b及1.0.2c版本。

上面的那些版本只能用一个月，考虑到Red Hat对重要漏洞的修复和功能选择的谨密政策，OpenSSL没有搭载任意一个上述功能。

Red Hat无需做任何东西去修复或减轻该漏洞（CVE-2015-1793），因为Red Hat不受该影响。



OpenSSL 7月9日安全修复（CVE-2015-1793)。

只是为了安全起见，如果可用，请尽快检查并进行更新。特别是如果你有软件使用了最新的OpenSSL源代码或其它库。
如何打补丁
和往常的补丁一样（参考：heartbleed（https://ma.ttias.be/patch-against-the-heartbleed-openssl-bug-cve-2014-0160/）, CVE-2015-0291) https://ma.ttias.be/openssl-cve-2015-0291-cve-2015-0286/） and CVE-2015-0286），修复一般需要两步，首先你得更新操作系统的各种库。

由于是“中间人”攻击，所以建议你重新所有服务或者应用程序连接到的SSL/TLS远程端点。如果有人试图改变你的远程端点的DNS并且把URL指向到自己的服务器，那么，你的程序可能依然会认为它是一个有效的的SSL/TLS流。
原文地址

OpenSSH <=6.8中存在一个安全问题，允许通过ssh-X连接客户端的恶意服务器连接到SSH客户端的X服务器，而不受X11的安全限制。

X验证：

    有客户端连接到X服务器时需要验证。验证可通过说明直接的验证信息（在实践中，它通常意味着要使用MIT-MAGIC-COOKIE-1，要求用户将一个验证“cookie”发送到服务器中）来完成，但也可通过间接方式完成——比如，对于本地连接来说，服务器可能会基于客户端的UID允许客户端进来。



    有意思的是，X 服务器会回退到间接验证方式，即使客户端已经直接说明了无效的验证数据。

X11SECURITY：

    X11安全机制允许用户创建magic cookies。当这些cookie用于X服务器验证时，它会限制客户端的行为。（这些cookie会阻止客户端使用不安全的X扩展并阻止访问不受限于X11 SECURITY 限制的windows，但不会阻止访问另外一个受限于X11 SECURITY限制的客户端windows。）

            由于所有带有X11 SECURITY限制的magic cookies都有相应的超时规定，如果cookie在超时规定的时间内没有被使用，它就会被删除。如果能够成功验证的客户端能够间接尝试通过过期且带有X11 SECURITY限制的cookie直接验证，那么直接验证就会失败，而且X服务器就会在没有X11 SECURITY的情况下回到间接验证！
 
（不受信任的） X 转发:

   当SSH客户端连接到带有ssh-X的SSH服务器时，SSH服务器能够通过已有的且客户端转发至本地X服务器的SSH隧道创建信道。X验证的处理如下：



     当连接至SSH服务器时，SSH客户端会在X服务器上注册一个使用期为ForwardX11Timeout（默认：20分钟）新的MIT magic cookie。这个cookie受限于X11 SECURITY限制。以下我将其称为“受限的cookie”。



   当连接至SSH服务器时，SSH客户端会创建一个看起来像MIT magic cookie的“虚拟cookie（dummy cookie）”。它会将这个字符串发送给SSH服务器，而位于SSH服务器上的X客户端在通过SSH验证X服务器时必须发送这个虚拟cookie。以下是蹩脚的一些ASCII信息流：

   这种方法的一个明显问题在于，如果在ForwardX11Timeout规定的时间内，不存在X客户端通过SSH隧道连接至X服务器的情况，那么服务器就会忘掉cookie。如果SSH客户端允许随后创建新连接，那么X服务器就不会识别出magic cookie，并且会使用通过unix域套接字连接的UID返回简介验证，给予X客户端不带X SECURITY 限制的访问权限。正因如此，超时过期后，ssh拒绝新的X11信道请求。

问题

准确地说，问题在于，ssh并不一定要在超时过期后阻拦对X服务器的新连接——而是必须阻拦X11的验证尝试。Cookie可能会在创建X服务器连接后、X客户端发送验证请求之前仍然过期。虽然连接创建之后通常直接跟着验证，但恶意攻击者可任意将其删除。攻击如下：

[]受害者（SSH客户端）与带有ssh-X的攻击者（SSH服务器）连接.[/][]攻击者等待19.5分钟.[/][]攻击者开启对SSH服务器的X11连接，SSH服务器要求在SSH连接上创建一个新的X11信道，SSH客户端连接至X服务器.[/][]攻击者等待1分钟，超时过期，X服务器忘记“受限的cookie”。SSH客户端不再允许新的X11信道.[/][]攻击者发送带有虚拟cookie的验证请求，SSH客户端发送带有“受限的cookie”的验证请求.[/][]攻击者与未受限于X SECURITY限制的X服务器互动.[/]

在实际操作中，可通过在调试器下及_xcb_get_auth_info启动一些X客户端的情况下创建一分钟的延时。等1分钟过后，让程序继续运行。
 
影响

   没有受限于X11限制的程序可以跟所有已打开的程序互动，就像这个程序就是你自己一样。例如，它能够访问所有你的所有公开终端windows并且使用XTEST扩展输入任意命令，这可能会允许SSH服务器完全攻陷任何与ssh-X连接的客户端。

例如，攻击者可以将任意内容发送给活跃的窗口，如：

修复方案:

   OpenSSH 6.9修复了这个问题，方法是：在SSH服务器请求一个新的X11信道时以及SSH服务器发送X11验证数据时检查超时过期。此外，由于“从一开始（off-by-one）”或时间倾斜在这里非常重要，因此MIT cookie的超时会增加一分钟，而ssh拒绝X11连接/验证尝试后超时不会发生变化。

原文地址

Openssl 7月9日发布了 OpenSSL 1.0.2  和OpenSSL 1.0.1 两个主线版本的更新，其中修复了一个高危安全问题(CVE-2015-1793)。

漏洞危害：

特定版本的OpenSSL在证书校验的逻辑中存在安全漏洞，使得攻击者可以绕过对不可信证书的检查。

影响范围 ：​

[]OpenSSL 1.0.2c [/]
[]OpenSSL 1.0.2b[/]
[]OpenSSL 1.0.1n[/]
[]OpenSSL 1.0.1o[/]
[]OpenSSL 0.9.8/1.0.0不受影响[/]

 
修复方案：

OpenSSL 1.0.2c/1.0.2b 的用户请升级到 1.0.2d



OpenSSL 1.0.1h/1.0.1o 的用户请升级到1.0.2p



前往http://www.openssl.org/ 下载相应版本自行编译升级。

该问题由Adam Langley/David Benjamin (Google/BoringSSL)于6月24日报告。
OpenSSL 安全公告:http://www.openssl.org/news/secadv_20150709.txt
原文地址

因为ES是java语言编写的程序，所以安装Elasticsearch唯一的要求是安装官方新版的Java下载地址
64位系统java安装脚本如下:

#!/usr/bin/env bash



java_install () {

rpm -qa | grep -i JDK;if [ $? -eq 0 ];then rpm -qa | grep -i JDK | xargs -n 1 -t rpm -e --nodeps;fi

os=$(uname -m)



if [ $os == "x86_64" ];then        

   cd /usr/local/src/

   wget -c http://118.186.221.78:8080/jdk-7u51-linux-x64.gz    (ip地址不是有效的，你换成你jdk下载地址就好)

   tar zxf jdk-7u51-linux-x64.gz -C /usr/local/



   sed -i 's@jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024@#jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024@g' /usr/local/jdk1.7.0_51/jre/lib/security/java.security

   ls /usr/bin/java* > /dev/null 2>&1;

   

   if [ $? -eq 0 ];then 

        ls /usr/bin/java*  | xargs -n 1 -t rm -rf

   else

        ln -s /usr/local/jdk1.7.0_51/bin/java /usr/bin/java

        ln -s /usr/local/jdk1.7.0_51/bin/javac /usr/bin/javac

        ln -s /usr/local/jdk1.7.0_51/bin/javadoc /usr/bin/javadoc

        ln -s /usr/local/jdk1.7.0_51/bin/javaws /usr/bin/javaws

   fi



   cd /usr/local/jdk1.7.0_51/

   echo "export JAVA_HOME=/usr/local/jdk1.7.0_51/" >> /root/.bashrc

   source /root/.bashrc

   echo "export PATH=$JAVA_HOME/bin:$PATH" >> /root/.bashrc

   echo "export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar" >> /root/.bashrc

   source /root/.bashrc

   echo "export JAVA_HOME=/usr/local/jdk1.7.0_51/" >> /etc/rc.local

fi



}

java_install

安装开始
你可以从 Downloads | Elasticsearch下载最新版本的Elasticsearch,进行安装：

curl -L -O “http://download.elasticsearch.org/PATH/TO/VERSION.zip”

unzip elasticsearch-$VERSION.zip

cd  elasticsearch-$VERSION

从 Downloads | Elasticsearch 获得最新可用的版本号并填入URL中

在生产环境安装时，除了以上方法，你还可以使用Debian或者RPM安装包，地址在这里:downloads page,或者也可以使用官方提供的Puppet module或者Chef cookbook。

安装Marvel
Marvel是Elasticsearch的管理和监控工具，在开发环境下免费使用。它包含了一个叫做Sense的交互式控制台，使用户方便的通过浏览器直接与Elasticsearch进行交互。
 
Elasticsearch线上文档中的很多示例代码都附带一个View in Sense的链接。点击进去，就会在Sense控制台打开相应的实例。安装Marvel不是必须的，但是它可以通过在你本地Elasticsearch集群中运行示例代码而增加与此书的互动性。
Marvel是一个插件，可在Elasticsearch目录中运行以下命令来下载和安装：

./bin/plugin -i elasticsearch/marvel/latest

你可能想要禁用监控，你可以通过以下命令关闭Marvel：

echo 'marvel.agent.enabled: false' >> ./config/elasticsearch.yml

运行Elasticsearch
Elasticsearch已经准备就绪，执行以下命令可在前台启动：

./bin/elasticsearch

如果想在后台以守护进程模式运行，添加-d参数。
 
打开另一个终端进行测试：

curl 'http://localhost:9200/?pretty'

你能看到以下返回信息：

{

   "status": 200,                           //状态码

   "name": "Shrunken Bones",                //默认集群名称

   "version": {

      "number": "1.4.0",                    //ES版本号

      "lucene_version": "4.10"              //lucene版本号

   },

   "tagline": "You Know, for Search"

}

这说明你的ELasticsearch集群已经启动并且正常运行，接下来我们可以开始各种实验了。
 
集群和节点

[b]节点(node)[/b]是一个运行着的Elasticsearch实例。[b]集群(cluster)[/b]是一组具有相同cluster.name的节点集合，他们协同工作，共享数据并提供故障转移和扩展功能，当然一个节点也可以组成一个集群。



你最好找一个合适的名字来替代cluster.name的默认值，比如你自己的名字，这样可以防止一个新启动的节点加入到相同网络中的另一个同名的集群中。



你可以通过修改config/目录下的elasticsearch.yml文件，然后重启ELasticsearch来做到这一点。当Elasticsearch在前台运行，可以使用Ctrl-C快捷键终止，或者你可以调用shutdown API来关闭：

查看Marvel和Sense
如果你安装了Marvel（作为管理和监控的工具），就可以在浏览器里通过以下地址访问它：
http://localhost:9200/_plugin/marvel/

你可以在Marvel中通过点击dashboards，在下拉菜单中访问Sense开发者控制台，或者直接访问以下地址：
http://localhost:9200/_plugin/marvel/sense/