部署管理工具:Chef vs Puppet vs Ansible vs SaltStack vs Fabric

OS小编 发表了文章 • 0 个评论 • 450 次浏览 • 2016-12-28 16:09 • 来自相关话题

Chef,Puppet,Ansible,SaltStack和Fabric的利弊是什么?

今天的生产经常意味着连续部署和分布在世界各地的环境。 当您的基础架构是分散式和基于云的,并且您正在处理在大部分相同的服务器上频繁部署大致相同的服务时,有一种方法来自动化配置和维护一切都是一大福音。 部署管理工具和配置管理工具是为此目的而设计的。 它们使您能够使用配方,剧本,模板或任何术语来简化环境中的自动化和编排,以提供标准,一致的部署。

在此空间中选择工具时,请记住几个注意事项。 一个是工具的模型。 一些需要主客户端模型,其使用集中控制点来与分布式机器通信,而其他人可以或者在更多本地级别上操作。 另一个考虑是你的环境的组成。 一些工具以不同的语言编写,并且对特定操作系统或设置的支持可以不同。 确保您选择的工具与您的环境和您的团队的特殊技能很好地融合在一起可以为您节省很多头痛。

1、Ansible





Ansible是用于在可重复的方式将应用程序部署到远程节点和配置服务器的开源工具。 它为您提供了使用推送模型设置推送多层应用程序和应用程序工件的通用框架,但如果愿意,您可以将其设置为主客户端。 Ansible是建立在playbooks,你可以应用于各种各样的系统部署你的应用程序。
 




这是Ansible Tower仪表板。
 
何时使用:如果起床和快速运行,方便地对你很重要,你不想安装在远程节点或托管服务器代理商,考虑Ansible。 如果你的需要或焦点更多在系统管理员方面,这是很好。 Ansible专注于精简和快速,所以如果这些是你的关键问题,给它一个镜头。
 
价格:有免费的开源版本,付费的Ansible Tower在$ 5,000每年(它给你多达100个节点)支付计划。
 
优点:
基于SSH,因此不需要在远程节点上安装任何代理。使用YAML语法易于学习。Playbook结构简单,结构清晰。具有可变注册功能,可使任务为以后的任务注册变量比一些其他工具更加精简的代码库
 缺点:
不如基于其他编程语言的工具强大。它的逻辑通过它的DSL,这意味着检查文档经常,直到你学习它即使是基本功能,也需要变量注册,这使得更简单的任务更复杂内省很差。 很难看到playbooks里的变量的价值输入,输出和配置文件的格式之间不一致性能和速度有待加强
Ansible介绍视频: https://www.youtube.com/watch?v=iVWmbStE1MM 

2、chef





Chef是配置管理的开源工具,专注于开发方为它的用户群。 厨师作为主客户端模型运行,具有控制主人所需的单独的工作站。 它基于Ruby,用纯Ruby编写的大多数元素。 厨师的设计是透明的,并根据它给出的说明,这意味着你必须确保你的说明是清楚的。
 




Chef DashBoard
 
何时使用:考虑使用Chef的时候需要保证你会使用Git/Ruby 因为书写配置的时候你会用到的。 Chef非常适合以开发为中心的团队和环境。 它对于寻找一个更加成熟的解决方案的企业非常适合异构环境。
 
价格:有免费的开源版本,每月的基础上的价格每节点的标准,保费计划,可以在高音量踏踏实实地分别为$ 6 /节点/月或$ 6.75 /节点/月。
 
优点:
丰富的模块和配置配方集合。代码驱动的方法为您的配置提供更多的控制和灵活性。围绕Git提供强大的版本控制功能。“Knife”工具(使用SSH从工作站部署代理)减轻了安装负担。
 
缺点:
如果你还不熟悉Ruby和过程编码,学习曲线是很陡峭的。这不是一个简单的工具,这可能导致大的代码库和复杂的环境。不支持推送功能。
Chef介绍视频:https://www.youtube.com/watch?v=kDeRHgnuDzc 

3、Fabric





Fabric是在应用程序部署精简SSH一个基于Python的工具。 它主要用于跨多个远程系统运行任务,但也可以使用插件扩展以提供更高级的功能。 Fabric将配置您的系统,执行系统/服务器管理,并自动部署您的应用程序。
 
何时使用:如果你只是在部署自动化领域起步的,Fabric是一个很好的起点。 如果你的环境涉及至少一点点Python,它是有帮助的。
 
价格:免费
 
优点:
擅长部署以任何语言编写的应用程序。 它不依赖于系统架构,而是OS和包管理器。比这个领域的其他工具更简单,更容易部署与SSH进行广泛集成,实现基于脚本的精简
 
缺点:
Fabric是单点故障设置(通常是您运行部署的机器)使用推模型,因此不太适合连续部署模型作为这个空间中的一些其他工具虽然它是用于在大多数语言中部署应用程序的一个很好的工具,但它需要Python运行,因此您的Fabric环境中必须至少有一个Python。
Fabric介绍视频:https://www.youtube.com/watch?v=VmcGuKPpWH8 

4、Puppet





Puppet是在全面配置管理空间长期工具之一。 它是一个开源工具,但考虑到它已经存在多久,它已经被良好的审查和部署在一些最大和最苛刻的环境中。 Puppet基于Ruby,但是使用更接近JSON的定制的域脚本语言(DSL)来在其中工作。 它作为主客户端设置运行,并使用模型驱动方法。 Puppet代码设计作为依赖关系列表,这可以使事情更容易或更混乱,这取决于您的设置。





Puppet企业仪表板
 
何时使用: Puppet是一个不错的选择,稳定性和成熟是你选择的关键因素。 它对于DevOps团队具有异构环境和技能范围的大型企业很有好处。
 
价格:Puppet可以使用免费开源版本,同时也提供收费企业版每年每节点$ 112与批量折扣付费商业企业版本。
 
优点:
通过Puppet Labs建立良好的支持社区。它有最成熟的接口,几乎在每个操作系统上运行。简单的安装和初始设置。在这个空间中最完整的Web UI。强大的报告功能。
 
缺点:
对于更高级的任务,您将需要使用基于Ruby的CLI(这意味着您必须理解Ruby)。支持纯Ruby版本(而不是使用Puppet的定制DSL)正在缩减。由于DSL和一个不专注于简单性的设计,Puppet代码库可能会变得庞大,笨重,难以在更高规模的组织中接纳新用户。与代码驱动方法相比,模型驱动方法意味着更少的控制。
Puppet介绍视频:https://www.youtube.com/watch?v=j8ImF23jZAg 

5、SaltStack





SaltStack(或Salt)是一个基于命令行的工具,可以设置一个主客户端模式还是非集中模式。 Salt基于Python,提供了一种推送方法和一种与客户端通信的SSH方法。 Salt允许对客户端和配置模板进行分组,以简化对环境的控制。
 
何时使用:Salt是一种不错的选择,如果可扩展性和永续性是一个大问题, 它对系统管理员很有好处,因为它的可用性比较好。
 
价格:免费的开源版本,这是基于每年每节点订阅的基础上SaltStack Enterprise版本。 具体定价不在他们的网站上列出(只是“联系我们”链接),但其他人报告每个节点每年150美元起点。
 
优点:
一旦您完成设置阶段,即可轻松组织和使用。他们的DSL是功能丰富,并不是逻辑和状态所必需的。输入,输出和配置非常一致 - 所有YAML。内省是非常好的。 很容易看到Salt内发生了什么。强大的社区。在主模型中具有minions和层级层次的高可扩展性和弹性。
 
缺点:
很难设置和挑选新用户。文档在介绍层面很难理解。Web UI比空间中的其他工具的Web UI更新,更不完整。对非Linux操作系统不是很大的支持。
SaltStack介绍视频:https://www.youtube.com/watch?v=TQjE2I8CrzQ 

Ansible vs. Chef vs. Fabric vs. Puppet vs. SaltStack

使用哪种配置管理或部署自动化工具将取决于您的环境的需求和首选项。 Chef和Puppet是一些较老的,更成熟的选择,使它们适合于那些重视成熟度和稳定性而不是简单性的大型企业和环境。 Ansible和SaltStack是那些寻求快速和简单的解决方案,而在不需要支持quirky功能或大量的操作系统的环境中工作的人的好选择。 面料是小型环境和那些寻求更低升力和入门级解决方案的好工具。
 
英文原文:http://blog.takipi.com/deployment-management-tools-chef-vs-puppet-vs-ansible-vs-saltstack-vs-fabric/  查看全部
chef.puppet_.ansibe_.saltstack_.fabric_.png


Chef,Puppet,Ansible,SaltStack和Fabric的利弊是什么?


今天的生产经常意味着连续部署和分布在世界各地的环境。 当您的基础架构是分散式和基于云的,并且您正在处理在大部分相同的服务器上频繁部署大致相同的服务时,有一种方法来自动化配置和维护一切都是一大福音。 部署管理工具和配置管理工具是为此目的而设计的。 它们使您能够使用配方,剧本,模板或任何术语来简化环境中的自动化和编排,以提供标准,一致的部署。

在此空间中选择工具时,请记住几个注意事项。 一个是工具的模型。 一些需要主客户端模型,其使用集中控制点来与分布式机器通信,而其他人可以或者在更多本地级别上操作。 另一个考虑是你的环境的组成。 一些工具以不同的语言编写,并且对特定操作系统或设置的支持可以不同。 确保您选择的工具与您的环境和您的团队的特殊技能很好地融合在一起可以为您节省很多头痛。


1、Ansible


ansible.png

Ansible是用于在可重复的方式将应用程序部署到远程节点和配置服务器的开源工具。 它为您提供了使用推送模型设置推送多层应用程序和应用程序工件的通用框架,但如果愿意,您可以将其设置为主客户端。 Ansible是建立在playbooks,你可以应用于各种各样的系统部署你的应用程序。
 
AnsibleDashboard.jpg

这是Ansible Tower仪表板。
 
何时使用:如果起床和快速运行,方便地对你很重要,你不想安装在远程节点或托管服务器代理商,考虑Ansible。 如果你的需要或焦点更多在系统管理员方面,这是很好。 Ansible专注于精简和快速,所以如果这些是你的关键问题,给它一个镜头。
 
价格:有免费的开源版本,付费的Ansible Tower在$ 5,000每年(它给你多达100个节点)支付计划。
 
优点:
  • 基于SSH,因此不需要在远程节点上安装任何代理。
  • 使用YAML语法易于学习。
  • Playbook结构简单,结构清晰。
  • 具有可变注册功能,可使任务为以后的任务注册变量
  • 比一些其他工具更加精简的代码库

 缺点
  • 不如基于其他编程语言的工具强大。
  • 它的逻辑通过它的DSL,这意味着检查文档经常,直到你学习它
  • 即使是基本功能,也需要变量注册,这使得更简单的任务更复杂
  • 内省很差。 很难看到playbooks里的变量的价值
  • 输入,输出和配置文件的格式之间不一致
  • 性能和速度有待加强

Ansible介绍视频: https://www.youtube.com/watch?v=iVWmbStE1MM 


2、chef


chef.png

Chef是配置管理的开源工具,专注于开发方为它的用户群。 厨师作为主客户端模型运行,具有控制主人所需的单独的工作站。 它基于Ruby,用纯Ruby编写的大多数元素。 厨师的设计是透明的,并根据它给出的说明,这意味着你必须确保你的说明是清楚的。
 
ChefBoard.jpg

Chef DashBoard
 
何时使用:考虑使用Chef的时候需要保证你会使用Git/Ruby 因为书写配置的时候你会用到的。 Chef非常适合以开发为中心的团队和环境。 它对于寻找一个更加成熟的解决方案的企业非常适合异构环境。
 
价格:有免费的开源版本,每月的基础上的价格每节点的标准,保费计划,可以在高音量踏踏实实地分别为$ 6 /节点/月或$ 6.75 /节点/月。
 
优点
  • 丰富的模块和配置配方集合。
  • 代码驱动的方法为您的配置提供更多的控制和灵活性。
  • 围绕Git提供强大的版本控制功能。
  • “Knife”工具(使用SSH从工作站部署代理)减轻了安装负担。

 
缺点:
  • 如果你还不熟悉Ruby和过程编码,学习曲线是很陡峭的。
  • 这不是一个简单的工具,这可能导致大的代码库和复杂的环境。
  • 不支持推送功能。

Chef介绍视频:https://www.youtube.com/watch?v=kDeRHgnuDzc 


3、Fabric


fabric.png

Fabric是在应用程序部署精简SSH一个基于Python的工具。 它主要用于跨多个远程系统运行任务,但也可以使用插件扩展以提供更高级的功能。 Fabric将配置您的系统,执行系统/服务器管理,并自动部署您的应用程序。
 
何时使用:如果你只是在部署自动化领域起步的,Fabric是一个很好的起点。 如果你的环境涉及至少一点点Python,它是有帮助的。
 
价格:免费
 
优点:
  • 擅长部署以任何语言编写的应用程序。 它不依赖于系统架构,而是OS和包管理器。
  • 比这个领域的其他工具更简单,更容易部署
  • 与SSH进行广泛集成,实现基于脚本的精简

 
缺点:
  • Fabric是单点故障设置(通常是您运行部署的机器)
  • 使用推模型,因此不太适合连续部署模型作为这个空间中的一些其他工具
  • 虽然它是用于在大多数语言中部署应用程序的一个很好的工具,但它需要Python运行,因此您的Fabric环境中必须至少有一个Python。

Fabric介绍视频:https://www.youtube.com/watch?v=VmcGuKPpWH8 


4、Puppet


Puppet.png

Puppet是在全面配置管理空间长期工具之一。 它是一个开源工具,但考虑到它已经存在多久,它已经被良好的审查和部署在一些最大和最苛刻的环境中。 Puppet基于Ruby,但是使用更接近JSON的定制的域脚本语言(DSL)来在其中工作。 它作为主客户端设置运行,并使用模型驱动方法。 Puppet代码设计作为依赖关系列表,这可以使事情更容易或更混乱,这取决于您的设置。

PuppetBoard.jpg

Puppet企业仪表板
 
何时使用: Puppet是一个不错的选择,稳定性和成熟是你选择的关键因素。 它对于DevOps团队具有异构环境和技能范围的大型企业很有好处。
 
价格:Puppet可以使用免费开源版本,同时也提供收费企业版每年每节点$ 112与批量折扣付费商业企业版本。
 
优点:
  • 通过Puppet Labs建立良好的支持社区。
  • 它有最成熟的接口,几乎在每个操作系统上运行。
  • 简单的安装和初始设置。
  • 在这个空间中最完整的Web UI。
  • 强大的报告功能。

 
缺点:
  • 对于更高级的任务,您将需要使用基于Ruby的CLI(这意味着您必须理解Ruby)。
  • 支持纯Ruby版本(而不是使用Puppet的定制DSL)正在缩减。
  • 由于DSL和一个不专注于简单性的设计,Puppet代码库可能会变得庞大,笨重,难以在更高规模的组织中接纳新用户。
  • 与代码驱动方法相比,模型驱动方法意味着更少的控制。

Puppet介绍视频:https://www.youtube.com/watch?v=j8ImF23jZAg 


5、SaltStack


saltstack.png

SaltStack(或Salt)是一个基于命令行的工具,可以设置一个主客户端模式还是非集中模式。 Salt基于Python,提供了一种推送方法和一种与客户端通信的SSH方法。 Salt允许对客户端和配置模板进行分组,以简化对环境的控制。
 
何时使用:Salt是一种不错的选择,如果可扩展性和永续性是一个大问题, 它对系统管理员很有好处,因为它的可用性比较好。
 
价格:免费的开源版本,这是基于每年每节点订阅的基础上SaltStack Enterprise版本。 具体定价不在他们的网站上列出(只是“联系我们”链接),但其他人报告每个节点每年150美元起点。
 
优点
  • 一旦您完成设置阶段,即可轻松组织和使用。
  • 他们的DSL是功能丰富,并不是逻辑和状态所必需的。
  • 输入,输出和配置非常一致 - 所有YAML。
  • 内省是非常好的。 很容易看到Salt内发生了什么。
  • 强大的社区。
  • 在主模型中具有minions和层级层次的高可扩展性和弹性。

 
缺点:
  • 很难设置和挑选新用户。
  • 文档在介绍层面很难理解。
  • Web UI比空间中的其他工具的Web UI更新,更不完整。
  • 对非Linux操作系统不是很大的支持。

SaltStack介绍视频:https://www.youtube.com/watch?v=TQjE2I8CrzQ 


Ansible vs. Chef vs. Fabric vs. Puppet vs. SaltStack


使用哪种配置管理或部署自动化工具将取决于您的环境的需求和首选项。 Chef和Puppet是一些较老的,更成熟的选择,使它们适合于那些重视成熟度和稳定性而不是简单性的大型企业和环境。 Ansible和SaltStack是那些寻求快速和简单的解决方案,而在不需要支持quirky功能或大量的操作系统的环境中工作的人的好选择。 面料是小型环境和那些寻求更低升力和入门级解决方案的好工具。
 
英文原文:http://blog.takipi.com/deployment-management-tools-chef-vs-puppet-vs-ansible-vs-saltstack-vs-fabric/ 

国内开源镜像站汇总分享

OS小编 发表了文章 • 0 个评论 • 226 次浏览 • 2016-12-27 17:43 • 来自相关话题

企业开源站

搜狐开源镜像站:http://mirrors.sohu.com/  
网易开源镜像站:http://mirrors.163.com/  
阿里开源镜像站:   http://mirrors.aliyun.com/ 
首都在线镜像站:http://mirrors.yun-idc.com/  
贝特康姆镜像站:http://centos.bitcomm.cn/  
Centos官方镜像: http://mirror-status.centos.org/  
 
 

大学教学站

中山大学镜像:http://mirror.sysu.edu.cn/ 
山东理工大学:http://mirrors.sdutlinux.org/ 
哈尔滨工业大学:http://run.hit.edu.cn/ 
中国地质大学:http://cugbteam.org/ 
大连理工大学:http://mirror.dlut.edu.cn/ 
西南林业大学 http://cs3.swfu.edu.cn/cs3guide.html 
北京化工大学(仅教育网可以访问),包含 CentOS 镜像:http://ubuntu.buct.edu.cn/ 
天津大学:http://mirror.tju.edu.cn/ 
西南大学:http://linux.swu.edu.cn/swudownload/Distributions/ 
青岛大学:http://mirror.qdu.edu.cn/ 
南京师范大学:http://mirrors.njnu.edu.cn/ 
大连东软信息学院: http://mirrors.neusoft.edu.cn/ 
浙江大学:http://mirrors.zju.edu.cn/ 
兰州大学:http://mirror.lzu.edu.cn/ 
厦门大学:http://mirrors.xmu.edu.cn/ 

北京理工大学:
http://mirror.bit.edu.cn   (IPv4 only)
http://mirror.bit6.edu.cn   (IPv6 only)

北京交通大学:
http://mirror.bjtu.edu.cn   (IPv4 only)
http://mirror6.bjtu.edu.cn   (IPv6 only)
http://debian.bjtu.edu.cn   (IPv4+IPv6)

上海交通大学:
http://ftp.sjtu.edu.cn/   (IPv4 only)
http://ftp6.sjtu.edu.cn   (IPv6 only)

清华大学:
http://mirrors.tuna.tsinghua.edu.cn/   (IPv4+IPv6)
http://mirrors.6.tuna.tsinghua.edu.cn/   (IPv6 only)
http://mirrors.4.tuna.tsinghua.edu.cn/   (IPv4 only)

中国科学技术大学:
http://mirrors.ustc.edu.cn/   (IPv4+IPv6)
http://mirrors4.ustc.edu.cn/  
http://mirrors6.ustc.edu.cn/  

东北大学:
http://mirror.neu.edu.cn/   (IPv4 only)
http://mirror.neu6.edu.cn/   (IPv6 only)

华中科技大学:
http://mirrors.hust.edu.cn/  
http://mirrors.hustunique.com/  

电子科技大学:http://ubuntu.uestc.edu.cn/  
电子科大凝聚工作室(Raspbian单一系统镜像) http://raspbian.cnssuestc.org/  
电子科大星辰工作室(少数小众发布版镜像) http://mirrors.stuhome.net/  
中国linux开源社团: http://mirrors.skyshe.cn/centos/  
 

HongKong

China - Hong Kong     Web Services Ltd.    http://mirror.vpshosting.com.hk/pub/linux/centos/
Hong Kong    01LINK NETWORK SERVICES LIMITED    http://centos.01link.hk/  
Hong Kong    CommuniLink Internet Limited    http://centos.communilink.net/       
Hong Kong    i-System Technology Limited    http://centos.uhost.hk/     
Hong Kong    SunnyVision Limited    http://mirror.sunnyvision.com/centos/          
Hong Kong    The Chinese University of Hong Kong    http://ftp.cuhk.edu.hk/pub/Linux/centos/         
Hong Kong    UDomain Web Hosting Company Ltd.    http://repo.virtualhosting.hk/centos/  
 

PyPi 镜像

豆瓣:http://pypi.douban.com/  
山东理工大学:http://pypi.sdutlinux.org/  
中山大学:http://mirror.sysu.edu.cn/pypi/  
V2EX:http://pypi.v2ex.com/simple/  
 

RubyGems 镜像

中山大学:http://mirror.sysu.edu.cn/rubygems/  
山东理工大学:http://ruby.sdutlinux.org/  
淘宝网:http://ruby.taobao.org/  
 

npm 镜像

cnpmjs:http://cnpmjs.org/  
 
为了为大家提供方便,这里收集了国内的开源站点,如果有错漏缺失之处,欢迎在文章下的评论中指出,然后更新。 查看全部
image.png


企业开源站


搜狐开源镜像站:http://mirrors.sohu.com/  
网易开源镜像站:http://mirrors.163.com/  
阿里开源镜像站:   http://mirrors.aliyun.com/ 
首都在线镜像站:http://mirrors.yun-idc.com/  
贝特康姆镜像站:http://centos.bitcomm.cn/  
Centos官方镜像: http://mirror-status.centos.org/  
 
 


大学教学站


中山大学镜像:http://mirror.sysu.edu.cn/ 
山东理工大学:http://mirrors.sdutlinux.org/ 
哈尔滨工业大学:http://run.hit.edu.cn/ 
中国地质大学:http://cugbteam.org/ 
大连理工大学:http://mirror.dlut.edu.cn/ 
西南林业大学 http://cs3.swfu.edu.cn/cs3guide.html 
北京化工大学(仅教育网可以访问),包含 CentOS 镜像:http://ubuntu.buct.edu.cn/ 
天津大学:http://mirror.tju.edu.cn/ 
西南大学:http://linux.swu.edu.cn/swudownload/Distributions/ 
青岛大学:http://mirror.qdu.edu.cn/ 
南京师范大学:http://mirrors.njnu.edu.cn/ 
大连东软信息学院: http://mirrors.neusoft.edu.cn/ 
浙江大学:http://mirrors.zju.edu.cn/ 
兰州大学:http://mirror.lzu.edu.cn/ 
厦门大学:http://mirrors.xmu.edu.cn/ 

北京理工大学:
http://mirror.bit.edu.cn   (IPv4 only)
http://mirror.bit6.edu.cn   (IPv6 only)

北京交通大学:
http://mirror.bjtu.edu.cn   (IPv4 only)
http://mirror6.bjtu.edu.cn   (IPv6 only)
http://debian.bjtu.edu.cn   (IPv4+IPv6)

上海交通大学:
http://ftp.sjtu.edu.cn/   (IPv4 only)
http://ftp6.sjtu.edu.cn   (IPv6 only)

清华大学:
http://mirrors.tuna.tsinghua.edu.cn/   (IPv4+IPv6)
http://mirrors.6.tuna.tsinghua.edu.cn/   (IPv6 only)
http://mirrors.4.tuna.tsinghua.edu.cn/   (IPv4 only)

中国科学技术大学:
http://mirrors.ustc.edu.cn/   (IPv4+IPv6)
http://mirrors4.ustc.edu.cn/  
http://mirrors6.ustc.edu.cn/  

东北大学:
http://mirror.neu.edu.cn/   (IPv4 only)
http://mirror.neu6.edu.cn/   (IPv6 only)

华中科技大学:
http://mirrors.hust.edu.cn/  
http://mirrors.hustunique.com/  

电子科技大学:http://ubuntu.uestc.edu.cn/  
电子科大凝聚工作室(Raspbian单一系统镜像) http://raspbian.cnssuestc.org/  
电子科大星辰工作室(少数小众发布版镜像) http://mirrors.stuhome.net/  
中国linux开源社团: http://mirrors.skyshe.cn/centos/  
 


HongKong


China - Hong Kong     Web Services Ltd.    http://mirror.vpshosting.com.hk/pub/linux/centos/
Hong Kong    01LINK NETWORK SERVICES LIMITED    http://centos.01link.hk/  
Hong Kong    CommuniLink Internet Limited    http://centos.communilink.net/       
Hong Kong    i-System Technology Limited    http://centos.uhost.hk/     
Hong Kong    SunnyVision Limited    http://mirror.sunnyvision.com/centos/          
Hong Kong    The Chinese University of Hong Kong    http://ftp.cuhk.edu.hk/pub/Linux/centos/         
Hong Kong    UDomain Web Hosting Company Ltd.    http://repo.virtualhosting.hk/centos/  
 


PyPi 镜像


豆瓣:http://pypi.douban.com/  
山东理工大学:http://pypi.sdutlinux.org/  
中山大学:http://mirror.sysu.edu.cn/pypi/  
V2EX:http://pypi.v2ex.com/simple/  
 


RubyGems 镜像


中山大学:http://mirror.sysu.edu.cn/rubygems/  
山东理工大学:http://ruby.sdutlinux.org/  
淘宝网:http://ruby.taobao.org/  
 


npm 镜像


cnpmjs:http://cnpmjs.org/  
 
为了为大家提供方便,这里收集了国内的开源站点,如果有错漏缺失之处,欢迎在文章下的评论中指出,然后更新。

如何为Kafka集群选择合适的主题和分区数量

Ansible 发表了文章 • 0 个评论 • 262 次浏览 • 2016-12-26 00:03 • 来自相关话题

这是许多Kafka用户提出的常见问题。 这篇文章的目的是解释几个重要的决定因素,并提供一些简单的公式。
 

更多的分区提供更高的吞吐量

首先要理解的是,主题分区是Kafka中并行性的单位。 在生产者和代理端,对不同分区的写入可以完全并行完成。 因此,昂贵的操作(例如压缩)可以利用更多的硬件资源。 在消费者方面,Kafka总是将一个分区的数据提供给一个消费者线程。 因此,消费者(在消费者组内)的并行度受所消耗的分区的数量的限制。 因此,一般来说,Kafka集群中的分区越多,吞吐量就越高。

用于选择分区数量的粗略公式基于吞吐量。 你衡量整个,你可以在生产单个分区(称之为P)和消费实现(称为C)。 比方说,你的目标吞吐量吨 。 然后,你需要至少有MAX(T / P,T / C)分区。 人们可以在生产者上实现的每分区吞吐量取决于诸如批处理大小,压缩编解码器,确认类型,复制因子等等的配置。然而,一般来说,可以在10秒的MB /如在此所示单个分区的基准 。 消费者吞吐量通常是与应用相关的,因为它对应于消费者逻辑可以如何快速地处理每个消息。 所以,你真的需要测量它。

虽然可以随着时间增加分区的数量,但是如果使用密钥生成消息,则必须小心。 当发布带密钥的消息时,Kafka基于密钥的散列将消息确定性地映射到分区。 这提供了保证具有相同密钥的消息总是路由到同一分区。 此保证对于某些应用可能是重要的,因为分区内的消息总是按顺序递送给消费者。 如果分区的数量改变,则这样的保证可能不再保持。 为了避免这种情况,一种常见的做法是过度分区。 基本上,您可以根据未来的目标吞吐量确定分区数,比如一两年后。 最初,您可以根据您的当前吞吐量只有一个小的Kafka集群。 随着时间的推移,您可以向集群添加更多代理,并按比例将现有分区的一部分移动到新代理(可以在线完成)。 这样,当使用密钥时,您可以跟上吞吐量增长,而不会破坏应用程序中的语义。

除了吞吐量,还有一些其他因素,在选择分区数时值得考虑。 正如你将看到的,在某些情况下,分区太多也可能产生负面影响。
 

更多分区需要打开更多的文件句柄

每个分区映射到broker中文件系统中的目录。 在该日志目录中,每个日志段将有两个文件(一个用于索引,另一个用于实际数据)。 目前,在Kafka中,每个broker打开每个日志段的索引和数据文件的文件句柄。 因此,分区越多,底层操作系统中需要配置打开文件句柄限制的分区越多。 这大多只是一个配置问题。 我们已经看到生产Kafka集群中,运行的每个broker打开的文件句柄数超过30000。
 

更多分区可能是不可用性增加

Kafka支持群集内复制 ,它提供更高的可用性和耐用性。 分区可以有多个副本,每个副本存储在不同的代理上。 其中一个副本被指定为领导者,其余的副本是追随者。 在内部,Kafka自动管理所有这些副本,并确保它们保持同步。 生产者和消费者对分区的请求都在领导副本上提供。 当代理失败时,该代理上具有leader的分区变得暂时不可用。 Kafka将自动将那些不可用分区的领导者移动到其他一些副本以继续服务客户端请求。 这个过程由指定为控制器的Kafka代理之一完成。 它涉及在ZooKeeper中为每个受影响的分区读取和写入一些元数据。 目前,ZooKeeper的操作是在控制器中串行完成的。

在通常情况下,当代理被干净地关闭时,控制器将主动地将领导者一次一个地关闭关闭代理。 单个领导者的移动只需要几毫秒。 因此,从客户的角度来看,在干净的代理关闭期间只有一小窗口的不可用性。

然而,当代理不干净地关闭(例如,kill -9)时,所观察到的不可用性可能与分区的数量成比例。 假设代理具有总共2000个分区,每个具有2个副本。 大致来说,这个代理将是大约1000个分区的领导者。 当这个代理不干净失败时,所有这1000个分区完全不能同时使用。 假设为单个分区选择新的领导需要5毫秒。 对于所有1000个分区,选择新的领导将需要5秒钟。 因此,对于一些分区,它们的观察到的不可用性可以是5秒加上检测故障所花费的时间。

如果一个是不幸的,失败的代理可能是控制器。 在这种情况下,选举新领导者的过程将不会开始,直到控制器故障转移到新的代理。 控制器故障转移自动发生,但需要新控制器在初始化期间从ZooKeeper读取每个分区的一些元数据。 例如,如果Kafka集群中有10,000个分区,并且从ZooKeeper初始化元数据每个分区需要2ms,则可以向不可用性窗口添加20多秒。

一般来说,不洁的故障是罕见的。 但是,如果在这种极少数情况下关心可用性,则可能最好将每个代理的分区数限制为两个到四千个,集群中的分区总数限制到几万个。
 

更多分区可能会增加端到端延迟

Kafka中的端到端延迟由从生产者发布消息到消费者读取消息的时间来定义。 Kafka仅在提交后向消费者公开消息,即,当消息被复制到所有同步副本时。 因此,提交消息的时间可以是端到端等待时间的显着部分。 默认情况下,对于在两个代理之间共享副本的所有分区,Kafka代理仅使用单个线程从另一个代理复制数据。 我们的实验表明,将1000个分区从一个代理复制到另一个代理可以添加大约20毫秒的延迟,这意味着端到端延迟至少为20毫秒。 这对于一些实时应用来说可能太高。

请注意,此问题在较大的群集上减轻。 例如,假设代理上有1000个分区引导,并且在同一个Kafka集群中有10个其他代理。 剩余的10个代理中的每个仅需要从第一代理平均获取100个分区。 因此,由于提交消息而增加的延迟将仅为几毫秒,而不是几十毫秒。

作为一个经验法则,如果你关心的延迟,它可能是一个好主意,每个经纪人的分区数量限制为100 * b * r,其中b是经纪人在kafka集群的数量和r是复制因子。
 

更多分区可能需要更多的内存在客户端

在最新的0.8.2版本,我们汇合到我们平台1.0,我们已经开发出一种更有效的Java生产商。 新生产者的一个好的功能是它允许用户设置用于缓冲传入消息的内存量的上限。 在内部,生产者缓冲每个分区的消息。 在累积了足够的数据或已经过去足够的时间之后,累积的消息从缓冲器中移除并发送到代理。

如果增加分区的数量,消息将在生产者中的更多分区中累积。 所使用的内存总量现在可能超过配置的内存限制。 当这种情况发生时,生产者必须阻止或丢弃任何新的消息,这两者都不是理想的。 为了防止这种情况发生,需要重新配置具有较大内存大小的生产者。

作为经验法则,为了实现良好的吞吐量,应该在生成器中分配至少几十KB的每个分区,并且如果分区的数量显着增加,则调整存储器的总量。

消费者也存在类似的问题。 消费者每个分区获取一批消息。 消费者消耗的分区越多,需要的内存就越多。 然而,这通常只是不是实时的消费者的问题。
 

总结

通常,Kafka集群中的更多分区导致更高的吞吐量。 然而,人们不得不意识到在总体上或每个代理中具有过多分区对可用性和等待时间的潜在影响。 在未来,我们计划改进一些限制,使Kafka在分区数方面更具可扩展性。
 

翻译原文:https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/  
作者:饶俊 查看全部
kafka.png

这是许多Kafka用户提出的常见问题。 这篇文章的目的是解释几个重要的决定因素,并提供一些简单的公式。
 


更多的分区提供更高的吞吐量


首先要理解的是,主题分区是Kafka中并行性的单位。 在生产者和代理端,对不同分区的写入可以完全并行完成。 因此,昂贵的操作(例如压缩)可以利用更多的硬件资源。 在消费者方面,Kafka总是将一个分区的数据提供给一个消费者线程。 因此,消费者(在消费者组内)的并行度受所消耗的分区的数量的限制。 因此,一般来说,Kafka集群中的分区越多,吞吐量就越高。

用于选择分区数量的粗略公式基于吞吐量。 你衡量整个,你可以在生产单个分区(称之为P)和消费实现(称为C)。 比方说,你的目标吞吐量吨 。 然后,你需要至少有MAX(T / P,T / C)分区。 人们可以在生产者上实现的每分区吞吐量取决于诸如批处理大小,压缩编解码器,确认类型,复制因子等等的配置。然而,一般来说,可以在10秒的MB /如在此所示单个分区的基准 。 消费者吞吐量通常是与应用相关的,因为它对应于消费者逻辑可以如何快速地处理每个消息。 所以,你真的需要测量它。

虽然可以随着时间增加分区的数量,但是如果使用密钥生成消息,则必须小心。 当发布带密钥的消息时,Kafka基于密钥的散列将消息确定性地映射到分区。 这提供了保证具有相同密钥的消息总是路由到同一分区。 此保证对于某些应用可能是重要的,因为分区内的消息总是按顺序递送给消费者。 如果分区的数量改变,则这样的保证可能不再保持。 为了避免这种情况,一种常见的做法是过度分区。 基本上,您可以根据未来的目标吞吐量确定分区数,比如一两年后。 最初,您可以根据您的当前吞吐量只有一个小的Kafka集群。 随着时间的推移,您可以向集群添加更多代理,并按比例将现有分区的一部分移动到新代理(可以在线完成)。 这样,当使用密钥时,您可以跟上吞吐量增长,而不会破坏应用程序中的语义。

除了吞吐量,还有一些其他因素,在选择分区数时值得考虑。 正如你将看到的,在某些情况下,分区太多也可能产生负面影响。
 


更多分区需要打开更多的文件句柄


每个分区映射到broker中文件系统中的目录。 在该日志目录中,每个日志段将有两个文件(一个用于索引,另一个用于实际数据)。 目前,在Kafka中,每个broker打开每个日志段的索引和数据文件的文件句柄。 因此,分区越多,底层操作系统中需要配置打开文件句柄限制的分区越多。 这大多只是一个配置问题。 我们已经看到生产Kafka集群中,运行的每个broker打开的文件句柄数超过30000。
 


更多分区可能是不可用性增加


Kafka支持群集内复制 ,它提供更高的可用性和耐用性。 分区可以有多个副本,每个副本存储在不同的代理上。 其中一个副本被指定为领导者,其余的副本是追随者。 在内部,Kafka自动管理所有这些副本,并确保它们保持同步。 生产者和消费者对分区的请求都在领导副本上提供。 当代理失败时,该代理上具有leader的分区变得暂时不可用。 Kafka将自动将那些不可用分区的领导者移动到其他一些副本以继续服务客户端请求。 这个过程由指定为控制器的Kafka代理之一完成。 它涉及在ZooKeeper中为每个受影响的分区读取和写入一些元数据。 目前,ZooKeeper的操作是在控制器中串行完成的。

在通常情况下,当代理被干净地关闭时,控制器将主动地将领导者一次一个地关闭关闭代理。 单个领导者的移动只需要几毫秒。 因此,从客户的角度来看,在干净的代理关闭期间只有一小窗口的不可用性。

然而,当代理不干净地关闭(例如,kill -9)时,所观察到的不可用性可能与分区的数量成比例。 假设代理具有总共2000个分区,每个具有2个副本。 大致来说,这个代理将是大约1000个分区的领导者。 当这个代理不干净失败时,所有这1000个分区完全不能同时使用。 假设为单个分区选择新的领导需要5毫秒。 对于所有1000个分区,选择新的领导将需要5秒钟。 因此,对于一些分区,它们的观察到的不可用性可以是5秒加上检测故障所花费的时间。

如果一个是不幸的,失败的代理可能是控制器。 在这种情况下,选举新领导者的过程将不会开始,直到控制器故障转移到新的代理。 控制器故障转移自动发生,但需要新控制器在初始化期间从ZooKeeper读取每个分区的一些元数据。 例如,如果Kafka集群中有10,000个分区,并且从ZooKeeper初始化元数据每个分区需要2ms,则可以向不可用性窗口添加20多秒。

一般来说,不洁的故障是罕见的。 但是,如果在这种极少数情况下关心可用性,则可能最好将每个代理的分区数限制为两个到四千个,集群中的分区总数限制到几万个。
 


更多分区可能会增加端到端延迟


Kafka中的端到端延迟由从生产者发布消息到消费者读取消息的时间来定义。 Kafka仅在提交后向消费者公开消息,即,当消息被复制到所有同步副本时。 因此,提交消息的时间可以是端到端等待时间的显着部分。 默认情况下,对于在两个代理之间共享副本的所有分区,Kafka代理仅使用单个线程从另一个代理复制数据。 我们的实验表明,将1000个分区从一个代理复制到另一个代理可以添加大约20毫秒的延迟,这意味着端到端延迟至少为20毫秒。 这对于一些实时应用来说可能太高。

请注意,此问题在较大的群集上减轻。 例如,假设代理上有1000个分区引导,并且在同一个Kafka集群中有10个其他代理。 剩余的10个代理中的每个仅需要从第一代理平均获取100个分区。 因此,由于提交消息而增加的延迟将仅为几毫秒,而不是几十毫秒。

作为一个经验法则,如果你关心的延迟,它可能是一个好主意,每个经纪人的分区数量限制为100 * b * r,其中b是经纪人在kafka集群的数量和r是复制因子。
 


更多分区可能需要更多的内存在客户端


在最新的0.8.2版本,我们汇合到我们平台1.0,我们已经开发出一种更有效的Java生产商。 新生产者的一个好的功能是它允许用户设置用于缓冲传入消息的内存量的上限。 在内部,生产者缓冲每个分区的消息。 在累积了足够的数据或已经过去足够的时间之后,累积的消息从缓冲器中移除并发送到代理。

如果增加分区的数量,消息将在生产者中的更多分区中累积。 所使用的内存总量现在可能超过配置的内存限制。 当这种情况发生时,生产者必须阻止或丢弃任何新的消息,这两者都不是理想的。 为了防止这种情况发生,需要重新配置具有较大内存大小的生产者。

作为经验法则,为了实现良好的吞吐量,应该在生成器中分配至少几十KB的每个分区,并且如果分区的数量显着增加,则调整存储器的总量。

消费者也存在类似的问题。 消费者每个分区获取一批消息。 消费者消耗的分区越多,需要的内存就越多。 然而,这通常只是不是实时的消费者的问题。
 


总结


通常,Kafka集群中的更多分区导致更高的吞吐量。 然而,人们不得不意识到在总体上或每个代理中具有过多分区对可用性和等待时间的潜在影响。 在未来,我们计划改进一些限制,使Kafka在分区数方面更具可扩展性。
 


翻译原文:https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/  
作者:饶俊


一个IP的主机上配置Nginx的多个HTTPS虚拟主机

Ansible 发表了文章 • 0 个评论 • 258 次浏览 • 2016-12-25 22:19 • 来自相关话题

最近公司域名更变,同时,又要新旧域名同时运行。 那么,对于https的域名在同一个IP上如何同时存在多个虚拟主机呢?查看了下nginx手册,有这么一段内容,如下:

如果在同一个IP上配置多个HTTPS主机,会出现一个很普遍的问题:server {
listen 443;
server_name www.example.com;
ssl on;
ssl_certificate www.example.com.crt;
...
}

server {
listen 443;
server_name www.example.org;
ssl on;
ssl_certificate www.example.org.crt;
...
}使用上面的配置,不论浏览器请求哪个主机,都只会收到默认主机www.example.com的证书。这是由SSL协议本身的行为引起的——先建立SSL连接,再发送HTTP请求,所以nginx建立SSL连接时不知道所请求主机的名字,因此,它只会返回默认主机的证书。

最古老的也是最稳定的解决方法就是每个HTTPS主机使用不同的IP地址:server {
listen 192.168.1.1:443;
server_name www.example.com;
ssl on;
ssl_certificate www.example.com.crt;
...
}

server {
listen 192.168.1.2:443;
server_name www.example.org;
ssl on;
ssl_certificate www.example.org.crt;
...
}那么,在同一个IP上,如何配置多个HTTPS主机呢?

nginx支持TLS协议的SNI扩展(Server Name Indication,简单地说这个扩展使得在同一个IP上可以以不同的证书serv不同的域名)。不过,SNI扩展还必须有客户端的支持,另外本地的OpenSSL必须支持它。

如果启用了SSL支持,nginx便会自动识别OpenSSL并启用SNI。是否启用SNI支持,是在编译时由当时的 ssl.h 决定的(SSL_CTRL_SET_TLSEXT_HOSTNAME),如果编译时使用的OpenSSL库支持SNI,则目标系统的OpenSSL库只要支持它就可以正常使用SNI了。

nginx在默认情况下是TLS SNI support disabled。

启用方法:
需要重新编译nginx并启用TLS。步骤如下:# wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
# tar zxvf openssl-1.0.1e.tar.gz
# ./configure --prefix=/usr/local/nginx --with-http_ssl_module \
--with-openssl=./openssl-1.0.1e \
--with-openssl-opt="enable-tlsext"
# make
# make install查看是否启用:# /usr/local/nginx/sbin/nginx -V
TLS SNI support enabled这样就可以在 同一个IP上配置多个HTTPS主机了。

实例如下:server {
listen 443;
server_name www.baidu.com;
index index.html index.htm index.php;
root /data/wwwroot/baidu/webroot;
ssl on;
ssl_certificate "/usr/local/nginx/conf/ssl/www.baidu.com.public.cer";
ssl_certificate_key "/usr/local/nginx/conf/ssl/www.baidu.com.private.key";
......
}

server {
listen 443;
server_name www.uko.com;
index index.html index.htm index.php;
root /data/wwwroot/www.uko.com/webroot;
ssl on;
ssl_certificate "/usr/local/nginx/conf/ssl/www.uko.com.public.cer";
ssl_certificate_key "/usr/local/nginx/conf/ssl/www.uko.com.private.key";
......
}分享阅读:http://www.ttlsa.com/web/multiple-https-host-nginx-with-a-ip-configuration/ 查看全部
最近公司域名更变,同时,又要新旧域名同时运行。 那么,对于https的域名在同一个IP上如何同时存在多个虚拟主机呢?查看了下nginx手册,有这么一段内容,如下:

如果在同一个IP上配置多个HTTPS主机,会出现一个很普遍的问题:
server {
listen 443;
server_name www.example.com;
ssl on;
ssl_certificate www.example.com.crt;
...
}

server {
listen 443;
server_name www.example.org;
ssl on;
ssl_certificate www.example.org.crt;
...
}
使用上面的配置,不论浏览器请求哪个主机,都只会收到默认主机www.example.com的证书。这是由SSL协议本身的行为引起的——先建立SSL连接,再发送HTTP请求,所以nginx建立SSL连接时不知道所请求主机的名字,因此,它只会返回默认主机的证书。

最古老的也是最稳定的解决方法就是每个HTTPS主机使用不同的IP地址:
server {
listen 192.168.1.1:443;
server_name www.example.com;
ssl on;
ssl_certificate www.example.com.crt;
...
}

server {
listen 192.168.1.2:443;
server_name www.example.org;
ssl on;
ssl_certificate www.example.org.crt;
...
}
那么,在同一个IP上,如何配置多个HTTPS主机呢?

nginx支持TLS协议的SNI扩展(Server Name Indication,简单地说这个扩展使得在同一个IP上可以以不同的证书serv不同的域名)。不过,SNI扩展还必须有客户端的支持,另外本地的OpenSSL必须支持它。

如果启用了SSL支持,nginx便会自动识别OpenSSL并启用SNI。是否启用SNI支持,是在编译时由当时的 ssl.h 决定的(SSL_CTRL_SET_TLSEXT_HOSTNAME),如果编译时使用的OpenSSL库支持SNI,则目标系统的OpenSSL库只要支持它就可以正常使用SNI了。

nginx在默认情况下是TLS SNI support disabled。

启用方法:
需要重新编译nginx并启用TLS。步骤如下:
# wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
# tar zxvf openssl-1.0.1e.tar.gz
# ./configure --prefix=/usr/local/nginx --with-http_ssl_module \
--with-openssl=./openssl-1.0.1e \
--with-openssl-opt="enable-tlsext"
# make
# make install
查看是否启用:
# /usr/local/nginx/sbin/nginx -V
TLS SNI support enabled
这样就可以在 同一个IP上配置多个HTTPS主机了。

实例如下:
server  {
listen 443;
server_name www.baidu.com;
index index.html index.htm index.php;
root /data/wwwroot/baidu/webroot;
ssl on;
ssl_certificate "/usr/local/nginx/conf/ssl/www.baidu.com.public.cer";
ssl_certificate_key "/usr/local/nginx/conf/ssl/www.baidu.com.private.key";
......
}

server {
listen 443;
server_name www.uko.com;
index index.html index.htm index.php;
root /data/wwwroot/www.uko.com/webroot;
ssl on;
ssl_certificate "/usr/local/nginx/conf/ssl/www.uko.com.public.cer";
ssl_certificate_key "/usr/local/nginx/conf/ssl/www.uko.com.private.key";
......
}
分享阅读:http://www.ttlsa.com/web/multiple-https-host-nginx-with-a-ip-configuration/

OpenSSH 远程代码执行漏洞安全预警

Geek小A 发表了文章 • 0 个评论 • 222 次浏览 • 2016-12-22 15:27 • 来自相关话题

概述

12 月 19 日,国外漏洞平台 securityfocus 上发布了最新的 OpenSSH(CVE-2016-10009) 远程代码执行漏洞。官方发布的openssh 7.4版本已经修复此漏洞,同时还修复了CVE-2016-10010、CVE-2016-10011、CVE-2016-10012和CVE-2016-8858。 请检查您使用版本是否在影响范围之内,并及时升级。
 

影响范围

OpenSSH 5.0 – 7.3
 

修复方案

请在升级前做好快照和文件备份,防止出现意外事件
1、升级到官网发布的 OpenSSH 7.4版本
注:升级openssh需要先将OpenSSL和Zlib升级到新版本
 

漏洞详情

CVE-2016-10009:黑客可通过此漏洞执行远程代码,或导致数据泄露。问题出在 ssh-agent ,这个进程默认不启动、只在多主机间免密码登录时才会用到,漏洞利用条件也比较苛刻,攻击者需要有控制agent-sock的权限和文件系统的写权限。官方漏洞评级为“中危”。

可以通过查看系统中是否有名为“ssh-agent ”的进程判断是否启用ssh-agent。

注:OpenSSH 7.4 已于 2016 年 12 月 19 日正式发布,新版本移植了在 Linux、BSD、以及其它类 Unix 平台上 SSH 2.0 协议的完整支持,主要修复了上一个版本中发现的 bug 和安全问题。需注意的是,7.4 版本的各项底层变化,有可能会影响现有的配置。

参考链接
https://www.openssh.com/txt/release-7.4 
http://seclists.org/oss-sec/2016/q4/708  查看全部
openssh.png


概述


12 月 19 日,国外漏洞平台 securityfocus 上发布了最新的 OpenSSH(CVE-2016-10009) 远程代码执行漏洞。官方发布的openssh 7.4版本已经修复此漏洞,同时还修复了CVE-2016-10010、CVE-2016-10011、CVE-2016-10012和CVE-2016-8858。 请检查您使用版本是否在影响范围之内,并及时升级。
 


影响范围


OpenSSH 5.0 – 7.3
 


修复方案


请在升级前做好快照和文件备份,防止出现意外事件
1、升级到官网发布的 OpenSSH 7.4版本
注:升级openssh需要先将OpenSSL和Zlib升级到新版本
 


漏洞详情


CVE-2016-10009:黑客可通过此漏洞执行远程代码,或导致数据泄露。问题出在 ssh-agent ,这个进程默认不启动、只在多主机间免密码登录时才会用到,漏洞利用条件也比较苛刻,攻击者需要有控制agent-sock的权限和文件系统的写权限。官方漏洞评级为“中危”。

可以通过查看系统中是否有名为“ssh-agent ”的进程判断是否启用ssh-agent。

注:OpenSSH 7.4 已于 2016 年 12 月 19 日正式发布,新版本移植了在 Linux、BSD、以及其它类 Unix 平台上 SSH 2.0 协议的完整支持,主要修复了上一个版本中发现的 bug 和安全问题。需注意的是,7.4 版本的各项底层变化,有可能会影响现有的配置。

参考链接
https://www.openssh.com/txt/release-7.4 
http://seclists.org/oss-sec/2016/q4/708 

CentOS下设置代理上网各种小技巧

Rock 发表了文章 • 0 个评论 • 221 次浏览 • 2016-12-21 16:37 • 来自相关话题

最近有人问CentOS如何设置各种代理上网;下面就为大家带来CentOS设置各种代理上网的方法;有需要的朋友可以看看。
 

1、网页上网​

桌面版的Centos的话,网页上网设置代理很简单,在firefox浏览器下 :
Edit-->>Preferences-->>Advanced-->>Network在Connection下点击Settings,里面的manual proxy configuration里设置IP和PORT即可。
 

2、yum代理设置

编辑文件为:/etc/yum.conf ,在里面添加这一行:proxy=IP:PORT这里的IP是你代理服务器的ip,端口也是你代理服务器的服务端口。
 

3、wget代理设置

编辑文件为:/etc/wgetrc , 添加下面两行:
http_proxy = IP:PORT
ftp_proxy = IP:PORT
 

4、系统环境代理设置

编辑文件为/etc/profile,如果只想给自己的账户设置,则编辑~/.bashrc即可
添加如下三行:
# add proxy for network
export http_proxy=http://child-prc.intel.com:913
export https_proxy=http://child-prc.intel.com:913
export ftp_proxy=$http_proxy然后source /etc/profile 或者source ~/.bashrc即可 查看全部
Centosimage.png

最近有人问CentOS如何设置各种代理上网;下面就为大家带来CentOS设置各种代理上网的方法;有需要的朋友可以看看。
 


1、网页上网​


桌面版的Centos的话,网页上网设置代理很简单,在firefox浏览器下 :
Edit-->>Preferences-->>Advanced-->>Network
在Connection下点击Settings,里面的manual proxy configuration里设置IP和PORT即可。
 


2、yum代理设置


编辑文件为:/etc/yum.conf ,在里面添加这一行:
proxy=IP:PORT
这里的IP是你代理服务器的ip,端口也是你代理服务器的服务端口。
 


3、wget代理设置


编辑文件为:/etc/wgetrc , 添加下面两行:
http_proxy = IP:PORT  
ftp_proxy = IP:PORT

 


4、系统环境代理设置


编辑文件为/etc/profile,如果只想给自己的账户设置,则编辑~/.bashrc即可
添加如下三行:
# add proxy for network
export http_proxy=http://child-prc.intel.com:913
export https_proxy=http://child-prc.intel.com:913
export ftp_proxy=$http_proxy
然后source /etc/profile 或者source ~/.bashrc即可

Centos下扩展PHP模块Imagick详解

being 发表了文章 • 0 个评论 • 206 次浏览 • 2016-12-20 20:39 • 来自相关话题

简介

imagick是一个PHP的扩展,它调用ImageMagick提供的API来进行图片的操作

ImageMagick是一套软件系列,主要用于图片的创建、编辑以及转换等,详细的解释见ImageMagick的官方网站http://www.imagemagick.org/  ,ImageMagick与GD的性能要高很多,如果是在处理大量的图片时更加能体现ImageMagick的性能。
 
通常安装安装php的imagick扩展模块有两种方法,一种是利用pcel安装imagick(适用于php verison 5.4 或者更高),第二种就是手动下载编译安装,下面依次介绍。

一、pcel安装imagick

1、首先安装ImageMagick# cd /usr/local/src/
# wget ftp://ftp.u-aizu.ac.jp/pub/graphics/image/ImageMagick/imagemagick.org/ImageMagick-6.8.7-0.tar.gz
# tar zxf ImageMagick-6.8.7-0.tar.gz
# cd ImageMagick-6.8.7-0
# ./configure -prefix=/usr/local/imagemagick
# make && make install官网地址:http://www.imagemagick.org/
 
2、安装imagick# 首先进入到PHP的bin目录
# cd /usr/local/php5.6.26/bin/
# ./pecl install imagick

................
Build process completed successfully
Installing '/usr/local/php5.6.26/lib/php/extensions/no-debug-non-zts-20131226/imagick.so'
Installing '/usr/local/php5.6.26/include/php/ext/imagick/php_imagick_shared.h'
install ok: channel://pecl.php.net/imagick-3.4.3RC1
configuration option "php_ini" is not set to php.ini location
You should add "extension=imagick.so" to php.ini产生的imagick.so文件拷贝到/usr/local/php5.6.26/lib/php/extensions/no-debug-non-zts-20131226下
 
在php.ini文件里添加imagick.so,然后重启php加载imagick模块即可,使用/usr/local/php5.6.26/bin/php -m 命令查看模块是否添加成功。

二、编译安装imagick

1、首先安装ImageMagick 同上
 
2、编译安装imagick# wget http://pecl.php.net/get/imagick-3.1.2.tgz
# tar zxf imagick-3.1.2.tgz
# cd imagick-3.1.2
# /usr/local/php5.3.6/bin/phpize (这个看你php安装路径)
# 注:phpize是一个shell脚本,主要是用来进行编译环境的准备,执行以后会生成一些新的文件,为配置、编译及安装作好准备
# ./configure --with-php-config=/usr/local/php5.3.6/bin/php-config --with-imagick=/usr/local/imagemagick
# make && make install在php配置文件php.ini中添加:extension=imagick.so重启apache或php-fpm就可以了。 查看全部
PHP.png


简介


imagick是一个PHP的扩展,它调用ImageMagick提供的API来进行图片的操作

ImageMagick是一套软件系列,主要用于图片的创建、编辑以及转换等,详细的解释见ImageMagick的官方网站http://www.imagemagick.org/  ,ImageMagick与GD的性能要高很多,如果是在处理大量的图片时更加能体现ImageMagick的性能。
 
通常安装安装php的imagick扩展模块有两种方法,一种是利用pcel安装imagick(适用于php verison 5.4 或者更高),第二种就是手动下载编译安装,下面依次介绍。


一、pcel安装imagick


1、首先安装ImageMagick
# cd /usr/local/src/
# wget ftp://ftp.u-aizu.ac.jp/pub/graphics/image/ImageMagick/imagemagick.org/ImageMagick-6.8.7-0.tar.gz
# tar zxf ImageMagick-6.8.7-0.tar.gz
# cd ImageMagick-6.8.7-0
# ./configure -prefix=/usr/local/imagemagick
# make && make install
官网地址:http://www.imagemagick.org/
 
2、安装imagick
# 首先进入到PHP的bin目录
# cd /usr/local/php5.6.26/bin/
# ./pecl install imagick

................
Build process completed successfully
Installing '/usr/local/php5.6.26/lib/php/extensions/no-debug-non-zts-20131226/imagick.so'
Installing '/usr/local/php5.6.26/include/php/ext/imagick/php_imagick_shared.h'
install ok: channel://pecl.php.net/imagick-3.4.3RC1
configuration option "php_ini" is not set to php.ini location
You should add "extension=imagick.so" to php.ini
产生的imagick.so文件拷贝到/usr/local/php5.6.26/lib/php/extensions/no-debug-non-zts-20131226下
 
在php.ini文件里添加imagick.so,然后重启php加载imagick模块即可,使用/usr/local/php5.6.26/bin/php -m 命令查看模块是否添加成功。


二、编译安装imagick


1、首先安装ImageMagick 同上
 
2、编译安装imagick
# wget http://pecl.php.net/get/imagick-3.1.2.tgz
# tar zxf imagick-3.1.2.tgz
# cd imagick-3.1.2
# /usr/local/php5.3.6/bin/phpize (这个看你php安装路径)
# 注:phpize是一个shell脚本,主要是用来进行编译环境的准备,执行以后会生成一些新的文件,为配置、编译及安装作好准备
# ./configure --with-php-config=/usr/local/php5.3.6/bin/php-config --with-imagick=/usr/local/imagemagick
# make && make install
在php配置文件php.ini中添加:
extension=imagick.so
重启apache或php-fpm就可以了。

流量劫持与防范

Ansible 发表了文章 • 0 个评论 • 262 次浏览 • 2016-12-20 18:47 • 来自相关话题

摘要

流量劫持现象在国内十分猖獗,6家国内顶级互联网公司呼吁有关运营商严格打击流量劫持问题。流量劫持分为域名劫持和内容篡改两类,通过HTTP DNS产品和内容HTTPS加密可以基本解决这两类问题。
 

概述

2015年12月15日,今日头条、美团大众点评网、360、腾讯、微博、小米科技六家公司发表联合声明,共同呼吁有关运营商严格打击流量劫持问题,重视互联网被流量劫持可能导致的严重后果。

联合声明指出,在当前的移动互联网环境下,流量劫持主要分为两种方式:域名劫持和数据劫持,放任流量劫持会导致扰乱市场秩序、损害用户利益以及传播诈骗、色情等低俗甚至严重违法信息的恶果。

而在2015年11月,上海浦东法院也刚刚对中国大陆地区首例流量劫持刑案作出判决,两名被告人被判有期徒刑三年,缓刑三年,扣押在案的作案工具以及没收退缴在案的违法所得。

在此前的很长时间内,流量劫持行为并没有被定义为刑事犯罪,而随着浦东法院的判决、六大互联网公司联合声明的发出,流量劫持正在得到更大范围的关注。如何防范流量劫持正成为各家互联网公司的探讨重点。

就此,记者联系了阿里云资深开发工程师亭林,请他介绍了流量劫持的技术原理以及相应的防范措施,精简分享如下。
 
相对于PC端的网络环境,移动端的网络环境更为复杂,2G、3G、4G、Wi-Fi各有不同,而复杂的网络环境也增加了流量劫持的可能性和复杂程度。
 
首先流量劫持的方式主要分为两种,域名劫持和数据劫持。
 

域名劫持

域名劫持是针对传统DNS解析的常见劫持方式。用户在浏览器输入网址,即发出一个HTTP请求,首先需要进行域名解析,得到业务服务器的IP地址。使用传统DNS解析时,会通过当地网络运营商提供的Local DNS解析得到结果。域名劫持,即是在请求Local DNS解析域名时出现问题,目标域名被恶意地解析到其他IP地址,造成用户无法正常使用服务。




解决域名劫持的一个办法就是绕开Local DNS,通过一个可信的源头来解析域名,解析方式不需要拘泥于DNS协议,也可以通过HTTP的方式。两年前,手机淘宝等APP也曾遇到这一问题,随后在做底层网络优化时,通过使用自己定制的HTTPDNS,一个安全可信的域名解析方案,解决了域名劫持问题。

HTTPDNS技术也准备通过阿里云平台开放给广大开发者使用,当前这款产品正在公测中,将于2016年3月29日提供商业化服务。到时,阿里云上的移动开发者也能自主选择,将需要防劫持的域名进行保护。
 

数据劫持

数据劫持基本针对明文传输的内容发生。用户发起HTTP请求,服务器返回页面内容时,经过中间的运营商网络,页面内容被篡改或加塞内容,强行插入弹窗或者广告。

行业内解决的办法即是对内容进行HTTPS加密,实现密文传输,彻底避免劫持问题。MD5校验同样能起到防止数据劫持的作用,MD5校验是指内容返回前,应用层对返回的数据进行校验,生成校验值;同时,内容接收方接收到内容后,也对内容进行校验,同样生成校验值,将这两个校验值进行比对,倘若一致,则可以判断数据无劫持。但相比HTTPS加密,MD5校验存在一定风险,劫持方技术能力强则有可能在篡改内容后替换校验值,导致接收方判断错误。

使用HTTPS加密,已经成为了互联网行业的大势所趋。今年双11,阿里的淘宝、天猫、聚划算等电商平台也都全面实现了HTTPS加密访问,全站改造投入巨大,但有效防止了资源被劫持,保障了用户的收发信息安全。未来,这一技术将不仅限于电商平台,还将通过阿里云对外输出,赋能更多的中小互联网企业,降低他们的创业成本,在更安全的移动互联网环境中得到发展。

阅读分享:https://yq.aliyun.com/articles/8656?spm=5176.100239.blogcont60033.8.zmhPUY 查看全部


摘要


流量劫持现象在国内十分猖獗,6家国内顶级互联网公司呼吁有关运营商严格打击流量劫持问题。流量劫持分为域名劫持和内容篡改两类,通过HTTP DNS产品和内容HTTPS加密可以基本解决这两类问题。
 


概述


2015年12月15日,今日头条、美团大众点评网、360、腾讯、微博、小米科技六家公司发表联合声明,共同呼吁有关运营商严格打击流量劫持问题,重视互联网被流量劫持可能导致的严重后果。

联合声明指出,在当前的移动互联网环境下,流量劫持主要分为两种方式:域名劫持和数据劫持,放任流量劫持会导致扰乱市场秩序、损害用户利益以及传播诈骗、色情等低俗甚至严重违法信息的恶果。

而在2015年11月,上海浦东法院也刚刚对中国大陆地区首例流量劫持刑案作出判决,两名被告人被判有期徒刑三年,缓刑三年,扣押在案的作案工具以及没收退缴在案的违法所得。

在此前的很长时间内,流量劫持行为并没有被定义为刑事犯罪,而随着浦东法院的判决、六大互联网公司联合声明的发出,流量劫持正在得到更大范围的关注。如何防范流量劫持正成为各家互联网公司的探讨重点。

就此,记者联系了阿里云资深开发工程师亭林,请他介绍了流量劫持的技术原理以及相应的防范措施,精简分享如下。
 
相对于PC端的网络环境,移动端的网络环境更为复杂,2G、3G、4G、Wi-Fi各有不同,而复杂的网络环境也增加了流量劫持的可能性和复杂程度。
 
首先流量劫持的方式主要分为两种,域名劫持和数据劫持。
 


域名劫持


域名劫持是针对传统DNS解析的常见劫持方式。用户在浏览器输入网址,即发出一个HTTP请求,首先需要进行域名解析,得到业务服务器的IP地址。使用传统DNS解析时,会通过当地网络运营商提供的Local DNS解析得到结果。域名劫持,即是在请求Local DNS解析域名时出现问题,目标域名被恶意地解析到其他IP地址,造成用户无法正常使用服务。
DnsDomain.png

解决域名劫持的一个办法就是绕开Local DNS,通过一个可信的源头来解析域名,解析方式不需要拘泥于DNS协议,也可以通过HTTP的方式。两年前,手机淘宝等APP也曾遇到这一问题,随后在做底层网络优化时,通过使用自己定制的HTTPDNS,一个安全可信的域名解析方案,解决了域名劫持问题。

HTTPDNS技术也准备通过阿里云平台开放给广大开发者使用,当前这款产品正在公测中,将于2016年3月29日提供商业化服务。到时,阿里云上的移动开发者也能自主选择,将需要防劫持的域名进行保护。
 


数据劫持


数据劫持基本针对明文传输的内容发生。用户发起HTTP请求,服务器返回页面内容时,经过中间的运营商网络,页面内容被篡改或加塞内容,强行插入弹窗或者广告。

行业内解决的办法即是对内容进行HTTPS加密,实现密文传输,彻底避免劫持问题。MD5校验同样能起到防止数据劫持的作用,MD5校验是指内容返回前,应用层对返回的数据进行校验,生成校验值;同时,内容接收方接收到内容后,也对内容进行校验,同样生成校验值,将这两个校验值进行比对,倘若一致,则可以判断数据无劫持。但相比HTTPS加密,MD5校验存在一定风险,劫持方技术能力强则有可能在篡改内容后替换校验值,导致接收方判断错误。

使用HTTPS加密,已经成为了互联网行业的大势所趋。今年双11,阿里的淘宝、天猫、聚划算等电商平台也都全面实现了HTTPS加密访问,全站改造投入巨大,但有效防止了资源被劫持,保障了用户的收发信息安全。未来,这一技术将不仅限于电商平台,还将通过阿里云对外输出,赋能更多的中小互联网企业,降低他们的创业成本,在更安全的移动互联网环境中得到发展。


阅读分享:https://yq.aliyun.com/articles/8656?spm=5176.100239.blogcont60033.8.zmhPUY


Python最差实践变更

chris 发表了文章 • 0 个评论 • 193 次浏览 • 2016-12-20 17:28 • 来自相关话题

最近在看一些陈年老系统,其中有一些不好的代码习惯遗留下来的坑;加上最近自己也写了一段烂代码导致服务器负载飙升,所以就趁此机会总结下我看到过/写过的自认为不好的Python代码习惯,时刻提醒自己远离这些“最差实践”,避免挖坑。

下面所举的例子中,有一部分会造成性能问题,有一部分会导致隐藏bug,或日后维护、重构困难,还有一部分纯粹是我认为不够pythonic。所以大家自行甄别,取精去糟吧。
 

函数默认参数使用可变对象​

这个例子我想大家应该在各种技术文章中见过许多遍了,也足以证明这是一个大坑。
 
先看错误示范吧:
def use_mutable_default_param(idx=0, ids=[]):
ids.append(idx)
print(idx)
print(ids)

use_mutable_default_param(idx=1)
use_mutable_default_param(idx=2)输出:
1
[1]
2
[1, 2]理解这其中的原因,最重要的是有两点:
函数本身也是一个对象,默认参数绑定于这个函数对象上append这类方法会直接修改对象,所以下次调用此函数时,其绑定的默认参数已经不再是空list了
 
正确的做法如下:
def donot_use_mutable_default_param(idx=0, ids=None):
if ids is None:
ids = []
ids.append(idx)
print(idx)
print(ids)

try…except不具体指明异常类型

虽然在Python中使用try…except不会带来严重的性能问题,但是不加区分,直接捕获所有类型异常的做法,往往会掩盖掉其他的bug,造成难以追查的bug。

一般的,我觉得应该尽量少的使用try…except,这样可以在开发期尽早的发现问题。即使要使用try…except,也应该尽可能的指定出要捕获的具体异常,并在except语句中将异常信息记入log,或者处理完之后,再直接raise出来。
 

关于dict的冗余代码

我经常能够看到这样的代码:
d = {}
datas = [1, 2, 3, 4, 2, 3, 4, 1, 5]
for k in datas:
if k not in d:
d[k] = 0
d[k] += 1其实,完全可以使用collections.defaultdict这一数据结构更简单优雅的实现这样的功能:
default_d = defaultdict(lambda: 0)
datas = [1, 2, 3, 4, 2, 3, 4, 1, 5]
for k in datas:
default_d[k] += 1 同样的,这样的代码:
# d is a dict
if 'list' not in d:
d['list'] = []
d['list'].append(x)完全可以用这样一行代码替代:
# d is a dict
d.setdefault('list', []).append(x)同样的,下面这两种写法一看就是带有浓浓的C味儿:
# d is a dict
for k in d:
v = d[k]
# do something

# l is a list
for i in len(l):
v = l[i]
# do something应该用更pythonic的写法:
# d is a dict
for k, v in d.iteritems():
# do something
pass

# l is a list
for i, v in enumerate(l):
# do something
pass另外,enumerate其实还有个第二参数,表示序号从几开始。如果想要序号从1开始数起,可以使用enumerate(l, 1)。 
 

使用flag变量而不使用for…else语句

同样,这样的代码也很常见:
search_list = ['Jone', 'Aric', 'Luise', 'Frank', 'Wey']
found = False
for s in search_list:
if s.startswith('C'):
found = True
# do something when found
print('Found')
break

if not found:
# do something when not found
print('Not found') 其实,用for…else更优雅:
search_list = ['Jone', 'Aric', 'Luise', 'Frank', 'Wey']
for s in search_list:
if s.startswith('C'):
# do something when found
print('Found')
break
else:
# do something when not found
print('Not found')

 

过度使用tuple unpacking

在Python中,允许对tuple类型进行unpack操作,如下所示:
# human = ('James', 180, 32)
name,height,age = human这个特性用起来很爽,比写name=human[0]之类的不知道高到哪里去了。所以,这一特性往往被滥用,一个human在程序的各处通过上面的方式unpack。

然而如果后来需要在human中插入一个表示性别的数据sex,那么对于所有的这种unpack都需要进行修改,即使在有些逻辑中并不会使用到性别。
# human = ('James', 180, 32)
name,height,age, _ = human
# or
# name, height, age, sex = human有如下几种方式解决这一问题:
老老实实写name=human[0]这种代码,在需要使用性别信息处加上sex=human[3]使用dict来表示human使用namedtuple
 
# human = namedtuple('human', ['name', 'height', 'age', 'sex'])
h = human('James', 180, 32, 0)
# then you can use h.name, h.sex and so on everywhere.

到处都是import *

import *是一种懒惰的行为,它不仅会污染当前的命名空间,并且还会使得pyflakes等代码检查工具失效。在后续查看代码或者debug的过程中,往往也很难从一堆import *中找到一个第三方函数的来源。

可以说这种习惯是百害而无一利的。
 

文件操作

文件操作不要使用裸奔的f = open(‘filename’)了,使用with open(‘filename’) as f来让context manager帮你处理异常情况下的关闭文件等乱七八糟的事情多好。
 

野蛮使用class.name判断类型

我曾经遇见过一个bug:为了实现某特定功能,我新写了一个class B(A),在B中重写了A的若干函数。整个实现很简单,但是就是有一部分A的功能无法生效。最后追查到的原因,就是在一些逻辑代码中,硬性的判断了entity.__class__.__name__ == ‘A’。

除非你就是想限定死继承层级中的当前类型(也就是,屏蔽未来可能会出现的子类),否则,不要使用__class__.__name__,而改用isinstance这个内建函数。毕竟,Python把这两个变量的名字都刻意带上那么多下划线,本来就是不太想让你用嘛。
 

循环内部有多层函数调用

循环内部有多层函数调用,有如下两方面的隐患:
Python没有inline函数,所以函数调用本来就会导致一定的开销,尤其是本身逻辑简单的时候,这个开销所占的比例就会挺可观的。更严重的是,在之后维护这份代码时,会容易让人忽略掉函数是在循环中被调用的,所以容易在函数内部添加了一些开销较大却不必每次循环都调用的函数,比如time.localtime()。如果是直接一个平铺直叙的循环,我想大部分的程序员都应该知道把time.localtime()写到循环的外面,但是引入多层的函数调用之后,就不一定了哦。
 
所以我建议,在循环内部,如非特别复杂的逻辑,都应该直接写在循环里,不要进行函数调用。如果一定要包装一层函数调用,应该在函数的命名或注释中,提示后续的维护者,这个函数会在循环内部使用。
 

总结

Python是一门非常容易入门的语言,严格的缩进要求和丰富的内置数据类型,使得大部分Python代码都能做到比较好的规范。但是,不严格要求自己,也很容易就写出犯二的代码。上面列出的只是很小的一部分,唯有多读、多写、多想,才能培养敏锐的代码嗅觉,第一时间发现坏味道啊。
 

分享阅读:http://blog.guoyb.com/2016/12/03/bad-py-style/
作者:yubo 查看全部
python.png
最近在看一些陈年老系统,其中有一些不好的代码习惯遗留下来的坑;加上最近自己也写了一段烂代码导致服务器负载飙升,所以就趁此机会总结下我看到过/写过的自认为不好的Python代码习惯,时刻提醒自己远离这些“最差实践”,避免挖坑。

下面所举的例子中,有一部分会造成性能问题,有一部分会导致隐藏bug,或日后维护、重构困难,还有一部分纯粹是我认为不够pythonic。所以大家自行甄别,取精去糟吧。
 


函数默认参数使用可变对象​


这个例子我想大家应该在各种技术文章中见过许多遍了,也足以证明这是一个大坑。
 
先看错误示范吧:
def use_mutable_default_param(idx=0, ids=[]):
ids.append(idx)
print(idx)
print(ids)

use_mutable_default_param(idx=1)
use_mutable_default_param(idx=2)
输出:
1
[1]
2
[1, 2]
理解这其中的原因,最重要的是有两点:
  1. 函数本身也是一个对象,默认参数绑定于这个函数对象上
  2. append这类方法会直接修改对象,所以下次调用此函数时,其绑定的默认参数已经不再是空list了

 
正确的做法如下:
def donot_use_mutable_default_param(idx=0, ids=None):
if ids is None:
ids = []
ids.append(idx)
print(idx)
print(ids)


try…except不具体指明异常类型


虽然在Python中使用try…except不会带来严重的性能问题,但是不加区分,直接捕获所有类型异常的做法,往往会掩盖掉其他的bug,造成难以追查的bug。

一般的,我觉得应该尽量少的使用try…except,这样可以在开发期尽早的发现问题。即使要使用try…except,也应该尽可能的指定出要捕获的具体异常,并在except语句中将异常信息记入log,或者处理完之后,再直接raise出来。
 


关于dict的冗余代码


我经常能够看到这样的代码:
d = {}
datas = [1, 2, 3, 4, 2, 3, 4, 1, 5]
for k in datas:
if k not in d:
d[k] = 0
d[k] += 1
其实,完全可以使用collections.defaultdict这一数据结构更简单优雅的实现这样的功能:
default_d = defaultdict(lambda: 0)
datas = [1, 2, 3, 4, 2, 3, 4, 1, 5]
for k in datas:
default_d[k] += 1
同样的,这样的代码:
# d is a dict
if 'list' not in d:
d['list'] = []
d['list'].append(x)
完全可以用这样一行代码替代:
# d is a dict
d.setdefault('list', []).append(x)
同样的,下面这两种写法一看就是带有浓浓的C味儿:
# d is a dict
for k in d:
v = d[k]
# do something

# l is a list
for i in len(l):
v = l[i]
# do something
应该用更pythonic的写法:
# d is a dict
for k, v in d.iteritems():
# do something
pass

# l is a list
for i, v in enumerate(l):
# do something
pass
另外,enumerate其实还有个第二参数,表示序号从几开始。如果想要序号从1开始数起,可以使用enumerate(l, 1)。 
 


使用flag变量而不使用for…else语句


同样,这样的代码也很常见:
search_list = ['Jone', 'Aric', 'Luise', 'Frank', 'Wey']
found = False
for s in search_list:
if s.startswith('C'):
found = True
# do something when found
print('Found')
break

if not found:
# do something when not found
print('Not found')
其实,用for…else更优雅:
search_list = ['Jone', 'Aric', 'Luise', 'Frank', 'Wey']
for s in search_list:
if s.startswith('C'):
# do something when found
print('Found')
break
else:
# do something when not found
print('Not found')

 


过度使用tuple unpacking


在Python中,允许对tuple类型进行unpack操作,如下所示:
# human = ('James', 180, 32)
name,height,age = human
这个特性用起来很爽,比写name=human[0]之类的不知道高到哪里去了。所以,这一特性往往被滥用,一个human在程序的各处通过上面的方式unpack。

然而如果后来需要在human中插入一个表示性别的数据sex,那么对于所有的这种unpack都需要进行修改,即使在有些逻辑中并不会使用到性别。
# human = ('James', 180, 32)
name,height,age, _ = human
# or
# name, height, age, sex = human
有如下几种方式解决这一问题:
  1. 老老实实写name=human[0]这种代码,在需要使用性别信息处加上sex=human[3]
  2. 使用dict来表示human
  3. 使用namedtuple

 
# human = namedtuple('human', ['name', 'height', 'age', 'sex'])
h = human('James', 180, 32, 0)
# then you can use h.name, h.sex and so on everywhere.


到处都是import *


import *是一种懒惰的行为,它不仅会污染当前的命名空间,并且还会使得pyflakes等代码检查工具失效。在后续查看代码或者debug的过程中,往往也很难从一堆import *中找到一个第三方函数的来源。

可以说这种习惯是百害而无一利的。
 


文件操作


文件操作不要使用裸奔的f = open(‘filename’)了,使用with open(‘filename’) as f来让context manager帮你处理异常情况下的关闭文件等乱七八糟的事情多好。
 


野蛮使用class.name判断类型


我曾经遇见过一个bug:为了实现某特定功能,我新写了一个class B(A),在B中重写了A的若干函数。整个实现很简单,但是就是有一部分A的功能无法生效。最后追查到的原因,就是在一些逻辑代码中,硬性的判断了entity.__class__.__name__ == ‘A’。

除非你就是想限定死继承层级中的当前类型(也就是,屏蔽未来可能会出现的子类),否则,不要使用__class__.__name__,而改用isinstance这个内建函数。毕竟,Python把这两个变量的名字都刻意带上那么多下划线,本来就是不太想让你用嘛。
 


循环内部有多层函数调用


循环内部有多层函数调用,有如下两方面的隐患:
  1. Python没有inline函数,所以函数调用本来就会导致一定的开销,尤其是本身逻辑简单的时候,这个开销所占的比例就会挺可观的。
  2. 更严重的是,在之后维护这份代码时,会容易让人忽略掉函数是在循环中被调用的,所以容易在函数内部添加了一些开销较大却不必每次循环都调用的函数,比如time.localtime()。如果是直接一个平铺直叙的循环,我想大部分的程序员都应该知道把time.localtime()写到循环的外面,但是引入多层的函数调用之后,就不一定了哦。

 
所以我建议,在循环内部,如非特别复杂的逻辑,都应该直接写在循环里,不要进行函数调用。如果一定要包装一层函数调用,应该在函数的命名或注释中,提示后续的维护者,这个函数会在循环内部使用。
 


总结


Python是一门非常容易入门的语言,严格的缩进要求和丰富的内置数据类型,使得大部分Python代码都能做到比较好的规范。但是,不严格要求自己,也很容易就写出犯二的代码。上面列出的只是很小的一部分,唯有多读、多写、多想,才能培养敏锐的代码嗅觉,第一时间发现坏味道啊。
 


分享阅读:http://blog.guoyb.com/2016/12/03/bad-py-style/
作者:yubo


邮件服务端口介绍

koyo 发表了文章 • 0 个评论 • 183 次浏览 • 2016-12-19 19:42 • 来自相关话题

25端口(SMTP):25端口为SMTP(Simple Mail Transfer Protocol,简单邮件传输协议)服务所开放的,是用于发送邮件。 
如今绝大多数邮件服务器都使用该协议。当你给别人发送邮件时,你的机器的某个动态端口(大于1024)就会与邮件服务器的25号端口建立一个连接,你发送的邮件就会通过这个连接传送到邮件服务器上,保存起来。
 
109端口(POP2):109端口是为POP2(Post Office Protocol Version2,邮局协议2)服务开放的,是用于接收邮件的。

110端口(POP3):110端口是为POP3(Post Office Protocol Version3,邮局协议3)服务开放的,是用于接收邮件的。

143端口(IMAP):143端口是为IMAP(INTERNET MESSAGE ACCESS PROTOCOL)服务开放的,是用于接收邮件的。

目前POP3使用的比POP2广得多,POP2几乎被淘汰,也有某些服务器同时支持POP2和POP3协议。客户端可以使用POP3协议来访问服务端的邮件服务,如今ISP的绝大多数邮件服务器都是使用POP3协议(极少用POP2协议)。在使用邮件客户端程序的时候,会要求输入POP3服务器地址,默认情况下使用的就是110端口。当你用邮件客户端(比如、Thunderbird、foxmail、MS Outlook Express以及各类邮件精灵)登录时,你的机器就会自动用机器的某一个动态端口(大于1024)连接邮件服务器的110端口,服务器就把别人给你发的邮件(之前保存在邮件服务器上),发送到你机器,这样你就可以看到你客户端工具上的收件箱里的新邮件了。

IMAP协议,和POP3协议一样是用来接收邮件的,但是它有它的特别和新颖之处,它是面向用户的,它和POP3协议的主要区别是:用户可以不用把所有的邮件内容全部下载,而是只下载邮件标题和发件人等基本信息,用户可以由标题等基本信息,去决定是否下载邮件全文,用户可以通过客户端的浏览器直接对服务器上的邮件进行操作(比如:打开阅读全文、丢进垃圾箱、永久删除、整理到某文件夹下、归档、)。再简单来说就是:浏览器用的IMAP协议(143端口)来为你接收邮件以及让你很方便的操作服务器上的邮件。邮件客户端用的POP3协议(110端口)来为你接收邮件的全部信息和全文内容保存到你的本地机器成为一个副本,你对邮件客户端上的副本邮件的任何操作都是在副本上,不干涉邮件服务器上为你保存的邮件原本。

上面介绍的SMTP协议、POP2协议、POP3协议、IMAP协议都是不安全的协议。因考虑到网络安全的因素,下面给你介绍基于SSL(Secure Sockets Layer 安全套接层)协议的安全的邮件收发协议。你的邮件在传输过程中可能被网络黑客截取邮件内容,如果你的邮件机密性非常强,不想被收件人以外的任何人和任何黑客截取,或者是涉及国家机密安全的,等等。那么你的邮件就不该使用上述的三种协议进行收发。

若你采用SMTP协议发邮件,那么你发出的邮件从你的机器传到服务器的过程中,可能被黑客截取从而泄露。若你采用POP2或者POP3协议收取邮件,那么你的邮件从服务器传至你当前机器的过程可能被黑客截取从而泄露。

465端口(SMTPS):465端口是为SMTPS(SMTP-over-SSL)协议服务开放的,这是SMTP协议基于SSL安全协议之上的一种变种协议,它继承了SSL安全协议的非对称加密的高度安全可靠性,可防止邮件泄露。SMTPS和SMTP协议一样,也是用来发送邮件的,只是更安全些,防止邮件被黑客截取泄露,还可实现邮件发送者抗抵赖功能。防止发送者发送之后删除已发邮件,拒不承认发送过这样一份邮件。

995端口(POP3S):995端口是为POP3S(POP3-over-SSL)协议服务开放的,这是POP3协议基于SSL安全协议之上的一种变种协议,它继承了SSL安全协议的非对称加密的高度安全可靠性,可防止邮件泄露。POP3S和POP3协议一样,也是用来接收邮件的,只是更安全些,防止邮件被黑客截取泄露,还可实现邮件接收方抗抵赖功能。防止收件者收件之后删除已收邮件,拒不承认收到过这样一封邮件。

993端口(IMAPS):993端口是为IMAPS(IMAP-over-SSL)协议服务开放的,这是IMAP协议基于SSL安全协议之上的一种变种协议,它继承了SSL安全协议的非对称加密的高度安全可靠性,可防止邮件泄露。IMAPS和IMAP协议一样,也是用来接收邮件的,只是更安全些,防止邮件被黑客截取泄露,还可实现邮件接收方抗抵赖功能。防止收件者收件之后删除已收邮件,拒不承认收到过这样一封邮件。 查看全部
mail.png

25端口(SMTP):25端口为SMTP(Simple Mail Transfer Protocol,简单邮件传输协议)服务所开放的,是用于发送邮件。 
如今绝大多数邮件服务器都使用该协议。当你给别人发送邮件时,你的机器的某个动态端口(大于1024)就会与邮件服务器的25号端口建立一个连接,你发送的邮件就会通过这个连接传送到邮件服务器上,保存起来。
 
109端口(POP2):109端口是为POP2(Post Office Protocol Version2,邮局协议2)服务开放的,是用于接收邮件的。

110端口(POP3):110端口是为POP3(Post Office Protocol Version3,邮局协议3)服务开放的,是用于接收邮件的。

143端口(IMAP):143端口是为IMAP(INTERNET MESSAGE ACCESS PROTOCOL)服务开放的,是用于接收邮件的。

目前POP3使用的比POP2广得多,POP2几乎被淘汰,也有某些服务器同时支持POP2和POP3协议。客户端可以使用POP3协议来访问服务端的邮件服务,如今ISP的绝大多数邮件服务器都是使用POP3协议(极少用POP2协议)。在使用邮件客户端程序的时候,会要求输入POP3服务器地址,默认情况下使用的就是110端口。当你用邮件客户端(比如、Thunderbird、foxmail、MS Outlook Express以及各类邮件精灵)登录时,你的机器就会自动用机器的某一个动态端口(大于1024)连接邮件服务器的110端口,服务器就把别人给你发的邮件(之前保存在邮件服务器上),发送到你机器,这样你就可以看到你客户端工具上的收件箱里的新邮件了。

IMAP协议,和POP3协议一样是用来接收邮件的,但是它有它的特别和新颖之处,它是面向用户的,它和POP3协议的主要区别是:用户可以不用把所有的邮件内容全部下载,而是只下载邮件标题和发件人等基本信息,用户可以由标题等基本信息,去决定是否下载邮件全文,用户可以通过客户端的浏览器直接对服务器上的邮件进行操作(比如:打开阅读全文、丢进垃圾箱、永久删除、整理到某文件夹下、归档、)。再简单来说就是:浏览器用的IMAP协议(143端口)来为你接收邮件以及让你很方便的操作服务器上的邮件。邮件客户端用的POP3协议(110端口)来为你接收邮件的全部信息和全文内容保存到你的本地机器成为一个副本,你对邮件客户端上的副本邮件的任何操作都是在副本上,不干涉邮件服务器上为你保存的邮件原本。

上面介绍的SMTP协议、POP2协议、POP3协议、IMAP协议都是不安全的协议。因考虑到网络安全的因素,下面给你介绍基于SSL(Secure Sockets Layer 安全套接层)协议的安全的邮件收发协议。你的邮件在传输过程中可能被网络黑客截取邮件内容,如果你的邮件机密性非常强,不想被收件人以外的任何人和任何黑客截取,或者是涉及国家机密安全的,等等。那么你的邮件就不该使用上述的三种协议进行收发。

若你采用SMTP协议发邮件,那么你发出的邮件从你的机器传到服务器的过程中,可能被黑客截取从而泄露。若你采用POP2或者POP3协议收取邮件,那么你的邮件从服务器传至你当前机器的过程可能被黑客截取从而泄露。

465端口(SMTPS):465端口是为SMTPS(SMTP-over-SSL)协议服务开放的,这是SMTP协议基于SSL安全协议之上的一种变种协议,它继承了SSL安全协议的非对称加密的高度安全可靠性,可防止邮件泄露。SMTPS和SMTP协议一样,也是用来发送邮件的,只是更安全些,防止邮件被黑客截取泄露,还可实现邮件发送者抗抵赖功能。防止发送者发送之后删除已发邮件,拒不承认发送过这样一份邮件。

995端口(POP3S):995端口是为POP3S(POP3-over-SSL)协议服务开放的,这是POP3协议基于SSL安全协议之上的一种变种协议,它继承了SSL安全协议的非对称加密的高度安全可靠性,可防止邮件泄露。POP3S和POP3协议一样,也是用来接收邮件的,只是更安全些,防止邮件被黑客截取泄露,还可实现邮件接收方抗抵赖功能。防止收件者收件之后删除已收邮件,拒不承认收到过这样一封邮件。

993端口(IMAPS):993端口是为IMAPS(IMAP-over-SSL)协议服务开放的,这是IMAP协议基于SSL安全协议之上的一种变种协议,它继承了SSL安全协议的非对称加密的高度安全可靠性,可防止邮件泄露。IMAPS和IMAP协议一样,也是用来接收邮件的,只是更安全些,防止邮件被黑客截取泄露,还可实现邮件接收方抗抵赖功能。防止收件者收件之后删除已收邮件,拒不承认收到过这样一封邮件。