解析一二线城市的互联网的“趋势 · 应用 · 互联”

OT学习平台 发表了文章 • 0 个评论 • 147 次浏览 • 4 天前 • 来自相关话题

过去20多年,互联网技术的革新引领时代的发展,加速向经济社会各领域渗透融合,不断催生新产品、新业务、新模式、新业态!

互联网+开始向各行各业渗透,从“人人相联”向“万物互联”迈进。在产业周期的更迭中,驱动全球互联网创新演进的资本、技术、数据、需求四大要素持续演化。

经济发展在新一代互联网产业中扮演什么角色?

传统企业如何实现信息化、数据化、在线化?

互联网企业如何引进来、走出去?

一线互联网技术人才视野在哪里?

二线互联网人才该如何进阶封神?

敬请关注12月10日9 : 00“中国【郑州】开发者大会”解码未来开发者直播活动,拥抱一线互联网技术趋势,关注技术在商业中的应用,积极实现一二线开发技术、思维、环境等的互联!

活动流程


09:00-09:05 主持人开场

09:05-09:15 主办方致辞:大象融媒负责人

09:15-09:25 主办方致辞:大象互联网圈发起人王向阳

09:25-09:45 技术创业下赛道的选择与实践:UU跑腿创始人&CEO乔松涛

09:45-10:05 工业大数据解决方案分享:阿里云架构师涂铭

10:05-10:25 移动端内容分发技术架构解析:迅雷AI以及推荐系统业务主管张升涛

10:25-10:45 详解车辆自动驾驶系统:宇通自动驾驶实验室第二负责人惠作奎

10:45-11:05 唯品会大数据架构及应用实践:唯品会资深数据架构师李创

11:05-11:50 趋势·应用·互联论坛

11:05-12:00 大象互联网圈&大象融媒战略签约仪式


13:30-14:00 面向未来的运维开发一体化——DevOps体系及实践:DevOps时代发起人、高效运维社区发起人萧田国

14:00-14:30 汽车之家数据库平台化实践:汽车之家架构师蔺瑞超

14:30-15:00 职场思考的快与慢:汽车之家开发经理李占斌

15:00-15:30 B站数据平台建设实践:Bilibili数据平台技术经理薛赵明

15:30-16:00 大数据营销:平安好房用户策略团队负责人胡辰

16:00-16:30 OpenPitrix平台中的微服务:开源文化布道、青云基础设施产品经理李建盛

16:30-17:00 基于人脸识别的人证合验采集平台的建设:中软高科产品经理张广举

17:00-17:50 拥抱·转型·发展论坛

17:50-18:00 项目展示时间

听企业家、互联网大牛们聊聊一二线互联网“趋势 · 应用 · 互联”那些事儿!

直播间入口:http://www.otpub.com/home/live/liveinfo/liveid/10082 查看全部
过去20多年,互联网技术的革新引领时代的发展,加速向经济社会各领域渗透融合,不断催生新产品、新业务、新模式、新业态!

互联网+开始向各行各业渗透,从“人人相联”向“万物互联”迈进。在产业周期的更迭中,驱动全球互联网创新演进的资本、技术、数据、需求四大要素持续演化。

经济发展在新一代互联网产业中扮演什么角色?

传统企业如何实现信息化、数据化、在线化?

互联网企业如何引进来、走出去?

一线互联网技术人才视野在哪里?

二线互联网人才该如何进阶封神?

敬请关注12月10日9 : 00“中国【郑州】开发者大会”解码未来开发者直播活动,拥抱一线互联网技术趋势,关注技术在商业中的应用,积极实现一二线开发技术、思维、环境等的互联!

活动流程


09:00-09:05 主持人开场

09:05-09:15 主办方致辞:大象融媒负责人

09:15-09:25 主办方致辞:大象互联网圈发起人王向阳

09:25-09:45 技术创业下赛道的选择与实践:UU跑腿创始人&CEO乔松涛

09:45-10:05 工业大数据解决方案分享:阿里云架构师涂铭

10:05-10:25 移动端内容分发技术架构解析:迅雷AI以及推荐系统业务主管张升涛

10:25-10:45 详解车辆自动驾驶系统:宇通自动驾驶实验室第二负责人惠作奎

10:45-11:05 唯品会大数据架构及应用实践:唯品会资深数据架构师李创

11:05-11:50 趋势·应用·互联论坛

11:05-12:00 大象互联网圈&大象融媒战略签约仪式


13:30-14:00 面向未来的运维开发一体化——DevOps体系及实践:DevOps时代发起人、高效运维社区发起人萧田国

14:00-14:30 汽车之家数据库平台化实践:汽车之家架构师蔺瑞超

14:30-15:00 职场思考的快与慢:汽车之家开发经理李占斌

15:00-15:30 B站数据平台建设实践:Bilibili数据平台技术经理薛赵明

15:30-16:00 大数据营销:平安好房用户策略团队负责人胡辰

16:00-16:30 OpenPitrix平台中的微服务:开源文化布道、青云基础设施产品经理李建盛

16:30-17:00 基于人脸识别的人证合验采集平台的建设:中软高科产品经理张广举

17:00-17:50 拥抱·转型·发展论坛

17:50-18:00 项目展示时间

听企业家、互联网大牛们聊聊一二线互联网“趋势 · 应用 · 互联”那些事儿!

直播间入口:http://www.otpub.com/home/live/liveinfo/liveid/10082

fir.im持续集成技术实践

OS小编 发表了文章 • 0 个评论 • 136 次浏览 • 2017-11-15 21:20 • 来自相关话题

互联网时代,人人都在追求产品的快速响应、快速迭代和快速验证。不论是创业团队还是大中型企业,都在探索属于自己的敏捷开发、持续交付之道。fir.im 团队也在全面实施敏捷,并推出新持续集成服务 — flow.ci ,以帮助企业将开发测试流程自动化,更快速地交付产品。 这篇文章将以实际开发为例,从敏捷方法论的角度来讲解 CI 技术实践与演变过程,大概分为三个部分,希望带给你一些参考。

持续集成做什么
持续集成的概念出现在 2001 年,它其实是一个 XP 极限编程的工程实践。那么持续的是什么,集成是什么呢,非常简单就是“一直不停地集成代码”。

持续集成是把代码频繁的合并到主干,通过自动构建的方式验证软件的质量,让团队快速的响应质量,快速的修复问题,快速的给客户解决问题,快速地交付更好的软件质量。

我们为什么要做持续集成
开发人员对下面的软件开发场景很熟悉,比如:
场景一:开发了新功能,老功能产生新的 bug;场景二:修好一个 bug,又产生其他 bug,甚至出现连环 bug;场景三:出现的 bug 比较多,修改代码要很谨慎,不熟悉的模块一般不敢动,怕引起问题;

持续集成是如何缓解这个问题,Martin Fowler 大师曾经说过:

“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” — Martin Fowler

如上面所说,持续集成不能消除 bug ,但能更容易地发现 bug,更快速地修复,提升产品质量。那么,持续集成能给我们带来哪些价值?




从这张图上可以看到,持续集成形成一个完美的闭环。通过持续的集成进行不断地检查、调整,同时,项目的透明性也得到了最大的体现。

fir.im 如何进行持续集成实践
这是一个常见的持续集成流水线:




在日常的开发过程中,程序员在本地提交代码,持续集成流水线要求先做一次本地集成,在本地进行验证后提交到源代码管理仓库中,之后源代码工具会发出 webhook 触发到持续集成系统中。当构建/测试完成后,会及时通过钉钉或邮件通知团队(测试/研发/boss/产品经理)集成状态,产品经理或项目经理收到通知后会在测试环境做验收测试,这是一个比较完美的反馈环。

假如测试通过验收完毕后,持续集成系统会自动触发部署到类生产环节或测试环境,或由专人手动部署到生产环境。

为什么要做本地集成
首先,代码在远程进行管理,每个人都会提交代码,远程的代码仓库会产生变化,所以在本地集成的时候要求进行代码合并,以免出现分支冲突和代码冲突。其次,不要依赖于持续集成系统给你结果,可能需要 30 分钟的时间,不要让开发人员等待,一定要先做本地集成。

如何做版本提交
再说一个提交的问题,我们尽量保证每一次提交都是一个完整的提交,也就是原子提交。

当代码变动你想创建提交时,这个提交应该尽可能的小量,并且包含一个不可分割的特性(feature)、修复(fix)或优化(improved)。

拿每个产品开发都会遇到的 login 功能开发举例,当填完的用户名和密码传到数据库,做完验证后给用户返回一个结果。那什么是一个原子提交?比如,提交验证一个用户名,这是一个完整的 feature ;验证密码是否符合格式(6位/8位),这也是一个完整的 feature ;当我验证完用户名和密码后再传到数据库之后,查询正确与否,这也是一个完整的 feature ;保证每次提交是一个完整的 feature 或修复了一个 bug,不要代码写成半截。

持续集成系统
这里讲的是狭义的持续集成系统,通常的 CI 系统收到提交之后会触发构建,构建会有信息返回比如 commit id 、commit 信息、代码变更等,收到代码提交后会触发自动构建,接着安装依赖进行编译,并触发质量保证流程,也就是说自动化测试集。




自动化测试集包括代码静态检查-单元测试-集成测试-验收测试-性能测试,也会有压力测试、回归测试、monkey test等等一系列的测试。




接下来,我们具体讲一下 fir.im 团队如何进行持续集成实践的。

fir.im 的敏捷环境
fir.im 是一个内测分发平台,我们也做了一个持续集成 CI 产品-flow.ci。先来看一下我们正在使用的敏捷环境:




Trello 看板;三个环境(类生产环境,测试环境,生产环境);CI 工具(Jenkins/flow.ci)

说一下 Git 分支管理
我们在应用 3 个分支 —— master/develop/feature 分支,对 feature 命名会有一些要求,持续集成系统一定会反馈到 trello 的 kanban 里,所以对于 feature 分支我们也有这样的命名 feature/fci-{card number} 以方便区分。




多分支如何做频繁地持续集成?
master 分支,即线上分支。线上通常会有一些 hotfix, 任何产品都不可能避免线上的 bug ,这些 bug 需要在 master 分支进行修复,修复完成后持续集成系统会告知已上线,收到团队反馈,这些代码会要求更新在 develop 分支上,之后所有团队也会收到相关通知,那么 feature 分支会有变化吗?答案是肯定的,因为频繁的集成可以防止代码偏离。这就是我们多分支构建的策略。




还有一个策略——不同的分支不同的构建,持续集成系统跑完整个流程会很长,所以在 feature 分支频繁度会比在本地构建要高一些,但是也没有那么高。为了保证持续集成系统能快速地收到反馈,需要在 feature 分支上做一些定制的 workflow ,所以我们做了代码静态分析和单元测试。

当 feature 分支的 card 做完之后(scrum 中 done 的含义是指测试验收完毕),集成到 develop 分支,develop 分支会自动部署到测试环境,会跑一个整个自动化测试集,为什么是这样的构建策略呢?

我们会做代码 review ,当 feature 分支提 pr 到 develop 分支上,这样 develop 分支的构建条件是:当收到 pr 之后,开始跑持续集成。假如部署完成整个测试跑过了产品经理验收之后,没毛病了,终于可以发布了到 master 分支。

整个团队的构建频率可以看下这张图:




本地集成的频率非常高,远程构建对应的是 feature 分支,会相对低一下。QA 环境对应的是 develop 分支的构建粒度。这样的构建每天都会产生,所以做完之后不要积压,一定要保持上线节奏。




kanban + scrum 结合的方式构成我们每日构建,这是一个整体的构建策略和上线频率。

fir.im 的持续集成系统演变过程
罗马不是一天建成的,持续集成不是一开始就是完美的,每个开发者心中都有一个比较理想的自动化工作流——持续部署,大概会经历这几个演变阶段:
最初阶段:提交代码-自动部署;一般进阶:提交代码-代码静态分析-自动部署,最简单先再加入代码静态分析;高级进阶:提交代码-代码静态分析-自动化测试集-自动部署;




这是我们在用的自动化测试集,下面分别说下静态检查分析、单元测试、验收测试、性能测试的具体用途。

Step 1. 静态代码分析
每个公司都会有自己的代码规范,代码静态分析工具能够保证代码质量,现成的工具有 java 的 FindBugs,ruby 的 rubocop 等。利用代码检查工具可以帮助团队发现可重构的地方,输出产出 – HTML 报告,也会发现潜在 bug;有的代码检查工具还会检查出一些安全漏洞。

这三点是代码静态分析最重要的作用。这里也分享一个 GitHub 地址,列出一些主流语言的代码分析工具,可以参考一下。

Step 2. “单元测试”
这里的 “单元测试”也加上了集成测试,毕竟创业公司要求资源最大化。程序员一定要写单元测试,要克服开发的惯性思维,不要甩锅。下面有一些注意的点和大家分享:
测试异常——不仅仅测试正确情况,也要主动测试异常;减少耦合——保证独立的可测试性;功能分离——单元测试流太长,超过 20 分钟的话要详细想一下如何将功能单独拆开,效率更高;测试=需求——从测试代码看到每个 class 是干什么的,同时出现 bug 时,第一时间是看测试,想想如何从测试中复现;

Step 3. 验收测试
验收测试是端对端的测试,从收到用户名密码到返回结果,是不是我们所期望的一个值,这是验收 Acceptance Test,其实是验收了整个功能。代码静态检查和单元测试,保证了我们如何怎么去写代码,验收测试保证了写正确代码,符合开发需求。

flow.ci 做验收测试比较多,用的是比较流行的框架 Cucumber + Selenium WebDriver,目前支持 3 种数据库,5 种 git 仓库,7 种 开发语言跑在 docker 容器云上,支持 iOS 构建跑在 mac 机器上,要保证这些排列组合正常运行,这是 flow.ci 做验收测试最核心的价值。




其实,持续集成是一个工作流,当 push 代码的时候才会 run 起来,但是 flow.ci 本身系统也有外部依赖的特殊性,会依赖一些第三方的 sevice(比如 GitHub/GitLab 等),验收测试应该一直保持不断地运行,也可以叫持续测试吧。因为我们永远不能保证第三方的 api 会不会改变:)

Step 4. 性能测试
我们的性能测试做的比较简单,主要测试 api.因为 fir.im 做 app 的内测分发,我们需要性能测试保证 app 上传下载的正常稳定。性能测试是单用户的,压力测试是多用户的,这是两者之间的区别。

性能测试会有一些不确定性,有很多系统会产生缓存。flow.ci 的性能测试跑在 docker 上,是一个干净独立的环境,需要让系统预热运行一下。Locust/JMeter/LoadRunner是目前比较流行的性能测试工具。 flow.ci 目前用的是 locust,可以参考一下。

持续集成的可视化、数据分析




说到数据统计分析,整个 ci 流程跑下来产生的很多数据也非常有挖掘的价值。比如,对于代码静态分析有多少 Offence、Risk、Bug,对于单元测试有失败率、测试覆盖率;对于验收测试或性能测试有多少的失败率,这些数据都有可能成为衡量一个程序员的标准。





结语
CI 就像盖楼房的脚手架一样,没有脚手架就没办法盖出一个足够高的楼,没有 CI 就无法交付质量足够好的软件!

分享阅读:http://blog.fir.im/firim_ci_practice/  查看全部
互联网时代,人人都在追求产品的快速响应、快速迭代和快速验证。不论是创业团队还是大中型企业,都在探索属于自己的敏捷开发、持续交付之道。fir.im 团队也在全面实施敏捷,并推出新持续集成服务 — flow.ci ,以帮助企业将开发测试流程自动化,更快速地交付产品。 这篇文章将以实际开发为例,从敏捷方法论的角度来讲解 CI 技术实践与演变过程,大概分为三个部分,希望带给你一些参考。

持续集成做什么
持续集成的概念出现在 2001 年,它其实是一个 XP 极限编程的工程实践。那么持续的是什么,集成是什么呢,非常简单就是“一直不停地集成代码”。

持续集成是把代码频繁的合并到主干,通过自动构建的方式验证软件的质量,让团队快速的响应质量,快速的修复问题,快速的给客户解决问题,快速地交付更好的软件质量。

我们为什么要做持续集成
开发人员对下面的软件开发场景很熟悉,比如:
  • 场景一:开发了新功能,老功能产生新的 bug;
  • 场景二:修好一个 bug,又产生其他 bug,甚至出现连环 bug;
  • 场景三:出现的 bug 比较多,修改代码要很谨慎,不熟悉的模块一般不敢动,怕引起问题;


持续集成是如何缓解这个问题,Martin Fowler 大师曾经说过:


“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” — Martin Fowler


如上面所说,持续集成不能消除 bug ,但能更容易地发现 bug,更快速地修复,提升产品质量。那么,持续集成能给我们带来哪些价值?
cic.jpg

从这张图上可以看到,持续集成形成一个完美的闭环。通过持续的集成进行不断地检查、调整,同时,项目的透明性也得到了最大的体现。

fir.im 如何进行持续集成实践
这是一个常见的持续集成流水线:
ciflow.jpg

在日常的开发过程中,程序员在本地提交代码,持续集成流水线要求先做一次本地集成,在本地进行验证后提交到源代码管理仓库中,之后源代码工具会发出 webhook 触发到持续集成系统中。当构建/测试完成后,会及时通过钉钉或邮件通知团队(测试/研发/boss/产品经理)集成状态,产品经理或项目经理收到通知后会在测试环境做验收测试,这是一个比较完美的反馈环。

假如测试通过验收完毕后,持续集成系统会自动触发部署到类生产环节或测试环境,或由专人手动部署到生产环境。

为什么要做本地集成
首先,代码在远程进行管理,每个人都会提交代码,远程的代码仓库会产生变化,所以在本地集成的时候要求进行代码合并,以免出现分支冲突和代码冲突。其次,不要依赖于持续集成系统给你结果,可能需要 30 分钟的时间,不要让开发人员等待,一定要先做本地集成。

如何做版本提交
再说一个提交的问题,我们尽量保证每一次提交都是一个完整的提交,也就是原子提交。


当代码变动你想创建提交时,这个提交应该尽可能的小量,并且包含一个不可分割的特性(feature)、修复(fix)或优化(improved)。


拿每个产品开发都会遇到的 login 功能开发举例,当填完的用户名和密码传到数据库,做完验证后给用户返回一个结果。那什么是一个原子提交?比如,提交验证一个用户名,这是一个完整的 feature ;验证密码是否符合格式(6位/8位),这也是一个完整的 feature ;当我验证完用户名和密码后再传到数据库之后,查询正确与否,这也是一个完整的 feature ;保证每次提交是一个完整的 feature 或修复了一个 bug,不要代码写成半截。

持续集成系统
这里讲的是狭义的持续集成系统,通常的 CI 系统收到提交之后会触发构建,构建会有信息返回比如 commit id 、commit 信息、代码变更等,收到代码提交后会触发自动构建,接着安装依赖进行编译,并触发质量保证流程,也就是说自动化测试集。
cisystem.jpg

自动化测试集包括代码静态检查-单元测试-集成测试-验收测试-性能测试,也会有压力测试、回归测试、monkey test等等一系列的测试。
cisystem2.jpg

接下来,我们具体讲一下 fir.im 团队如何进行持续集成实践的。

fir.im 的敏捷环境
fir.im 是一个内测分发平台,我们也做了一个持续集成 CI 产品-flow.ci。先来看一下我们正在使用的敏捷环境:
Agilefirim.png

  • Trello 看板;
  • 三个环境(类生产环境,测试环境,生产环境);
  • CI 工具(Jenkins/flow.ci)


说一下 Git 分支管理
我们在应用 3 个分支 —— master/develop/feature 分支,对 feature 命名会有一些要求,持续集成系统一定会反馈到 trello 的 kanban 里,所以对于 feature 分支我们也有这样的命名 feature/fci-{card number} 以方便区分。
gitbranchm.jpg

多分支如何做频繁地持续集成?
master 分支,即线上分支。线上通常会有一些 hotfix, 任何产品都不可能避免线上的 bug ,这些 bug 需要在 master 分支进行修复,修复完成后持续集成系统会告知已上线,收到团队反馈,这些代码会要求更新在 develop 分支上,之后所有团队也会收到相关通知,那么 feature 分支会有变化吗?答案是肯定的,因为频繁的集成可以防止代码偏离。这就是我们多分支构建的策略。
fzce.jpg

还有一个策略——不同的分支不同的构建,持续集成系统跑完整个流程会很长,所以在 feature 分支频繁度会比在本地构建要高一些,但是也没有那么高。为了保证持续集成系统能快速地收到反馈,需要在 feature 分支上做一些定制的 workflow ,所以我们做了代码静态分析和单元测试。

当 feature 分支的 card 做完之后(scrum 中 done 的含义是指测试验收完毕),集成到 develop 分支,develop 分支会自动部署到测试环境,会跑一个整个自动化测试集,为什么是这样的构建策略呢?


我们会做代码 review ,当 feature 分支提 pr 到 develop 分支上,这样 develop 分支的构建条件是:当收到 pr 之后,开始跑持续集成。假如部署完成整个测试跑过了产品经理验收之后,没毛病了,终于可以发布了到 master 分支。


整个团队的构建频率可以看下这张图:
Build-frequency.jpg

本地集成的频率非常高,远程构建对应的是 feature 分支,会相对低一下。QA 环境对应的是 develop 分支的构建粒度。这样的构建每天都会产生,所以做完之后不要积压,一定要保持上线节奏。
kanban.png

kanban + scrum 结合的方式构成我们每日构建,这是一个整体的构建策略和上线频率。

fir.im 的持续集成系统演变过程
罗马不是一天建成的,持续集成不是一开始就是完美的,每个开发者心中都有一个比较理想的自动化工作流——持续部署,大概会经历这几个演变阶段:
  • 最初阶段:提交代码-自动部署;
  • 一般进阶:提交代码-代码静态分析-自动部署,最简单先再加入代码静态分析;
  • 高级进阶:提交代码-代码静态分析-自动化测试集-自动部署;

flow.jpg

这是我们在用的自动化测试集,下面分别说下静态检查分析、单元测试、验收测试、性能测试的具体用途。

Step 1. 静态代码分析
每个公司都会有自己的代码规范,代码静态分析工具能够保证代码质量,现成的工具有 java 的 FindBugs,ruby 的 rubocop 等。利用代码检查工具可以帮助团队发现可重构的地方,输出产出 – HTML 报告,也会发现潜在 bug;有的代码检查工具还会检查出一些安全漏洞。

这三点是代码静态分析最重要的作用。这里也分享一个 GitHub 地址,列出一些主流语言的代码分析工具,可以参考一下。

Step 2. “单元测试”
这里的 “单元测试”也加上了集成测试,毕竟创业公司要求资源最大化。程序员一定要写单元测试,要克服开发的惯性思维,不要甩锅。下面有一些注意的点和大家分享:
  • 测试异常——不仅仅测试正确情况,也要主动测试异常;
  • 减少耦合——保证独立的可测试性;
  • 功能分离——单元测试流太长,超过 20 分钟的话要详细想一下如何将功能单独拆开,效率更高;
  • 测试=需求——从测试代码看到每个 class 是干什么的,同时出现 bug 时,第一时间是看测试,想想如何从测试中复现;


Step 3. 验收测试
验收测试是端对端的测试,从收到用户名密码到返回结果,是不是我们所期望的一个值,这是验收 Acceptance Test,其实是验收了整个功能。代码静态检查和单元测试,保证了我们如何怎么去写代码,验收测试保证了写正确代码,符合开发需求。

flow.ci 做验收测试比较多,用的是比较流行的框架 Cucumber + Selenium WebDriver,目前支持 3 种数据库,5 种 git 仓库,7 种 开发语言跑在 docker 容器云上,支持 iOS 构建跑在 mac 机器上,要保证这些排列组合正常运行,这是 flow.ci 做验收测试最核心的价值。
value.jpg

其实,持续集成是一个工作流,当 push 代码的时候才会 run 起来,但是 flow.ci 本身系统也有外部依赖的特殊性,会依赖一些第三方的 sevice(比如 GitHub/GitLab 等),验收测试应该一直保持不断地运行,也可以叫持续测试吧。因为我们永远不能保证第三方的 api 会不会改变:)

Step 4. 性能测试
我们的性能测试做的比较简单,主要测试 api.因为 fir.im 做 app 的内测分发,我们需要性能测试保证 app 上传下载的正常稳定。性能测试是单用户的,压力测试是多用户的,这是两者之间的区别。

性能测试会有一些不确定性,有很多系统会产生缓存。flow.ci 的性能测试跑在 docker 上,是一个干净独立的环境,需要让系统预热运行一下。Locust/JMeter/LoadRunner是目前比较流行的性能测试工具。 flow.ci 目前用的是 locust,可以参考一下。

持续集成的可视化、数据分析
view.jpg

说到数据统计分析,整个 ci 流程跑下来产生的很多数据也非常有挖掘的价值。比如,对于代码静态分析有多少 Offence、Risk、Bug,对于单元测试有失败率、测试覆盖率;对于验收测试或性能测试有多少的失败率,这些数据都有可能成为衡量一个程序员的标准。
dataview.jpg


结语
CI 就像盖楼房的脚手架一样,没有脚手架就没办法盖出一个足够高的楼,没有 CI 就无法交付质量足够好的软件!


分享阅读:http://blog.fir.im/firim_ci_practice/ 


理解持续集成、持续交付、持续部署

OS小编 发表了文章 • 0 个评论 • 122 次浏览 • 2017-11-15 00:14 • 来自相关话题

「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」这三个概念有很详细的解释。这里借用文中的插图,说一下我对这三个概念的理解。
 
持续集成




持续集成强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。
 
持续交付




持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。
 
持续部署




持续部署则是在持续交付的基础上,把部署到生产环境的过程自动化。我个人觉得持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题导致返工,而持续集成、持续交付、持续部署恰恰可以早发现早解决,从而可以避免这个问题。
 
参考:https://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/  查看全部
「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」这三个概念有很详细的解释。这里借用文中的插图,说一下我对这三个概念的理解。
 
持续集成
xci.jpg

持续集成强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。
 
持续交付
xcd.jpg

持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。
 
持续部署
xcr.jpg

持续部署则是在持续交付的基础上,把部署到生产环境的过程自动化。我个人觉得持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题导致返工,而持续集成、持续交付、持续部署恰恰可以早发现早解决,从而可以避免这个问题。
 
参考:https://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/ 

谈谈持续集成、持续交付、持续部署之间的区别

OS小编 发表了文章 • 0 个评论 • 122 次浏览 • 2017-11-14 22:50 • 来自相关话题

经常会听到持续集成,持续交付,持续部署,三者究竟是什么,有何联系和区别呢?




假如把开发工作流程分为以下几个阶段:

编码 ---> 构建 ---> 集成 ---> 测试 ---> 交付 ---> 部署

正如你在上图中看到,「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期。
 
持续集成
持续集成是指软件个人研发的部分向软件整体部分交付,频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程(XP),是 XP 最初的 12 种实践之一。




CI 需要具备这些:
全面的自动化测试: 这是实践持续集成&持续部署的基础,同时,选择合适的自动化测试工具也极其重要;灵活的基础设施: 容器,虚拟机的存在让开发人员和 QA 人员不必再大费周折;版本控制工具: 如 Git,CVS,SVN 等;自动化的构建和软件发布流程的工具,如 Jenkins,flow.ci;反馈机制: 如构建/测试的失败,可以快速地反馈到相关负责人,以尽快解决达到一个更稳定的版本。
持续集成的优点:
“快速失败”,在对产品没有风险的情况下进行测试,并快速响应;最大限度地减少风险,降低修复错误代码的成本;将重复性的手工流程自动化,让工程师更加专注于代码;保持频繁部署,快速生成可部署的软件;提高项目的能见度,方便团队成员了解项目的进度和成熟度;增强开发人员对软件产品的信心,帮助建立更好的工程师文化。
 
持续集成,该从何入手
最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统,关键在于团队运行的基础设施,团队对持续集成系统的资源投入力度。

对比一下私有部署和托管型持续集成系统,或许能帮助你更好地做出选择。
Self Hosted CI 指的是将软件部署在公司的机房或内网中,需要提供多台服务器来完成 CI 系统的运转,同时需要对不同机器之间进行环境配置。比如Maven 或 Gradle 或 Jenkins ,他们的特点是自由开源,且文档支持广泛。优点在于对构建环境有完全的控制权,能够实现完全定制。但需要搭建环境和配置、维护成本高,需要买专门的机器,花费较多人力物力且更新迁移风险高;

Hosted CI 指的是由 SaaS 型的 CI 服务,全程在线进行构建配置,不需要考虑装机器,装软件,环境搭建等成本。常见的有 CircleCI,Codeship 和 TravisCI 等,还有国内最新的持续集成服务——flow.ci 。SaaS 型的 CI 的特点在于无需额外机器,几分钟就可以用起来。可以根据你的需要动态调度资源。省时,省心,省力。
 
整体而言,Jenkins 过去一直是大部分公司的选择,但这个现象正在发生改变,随着公有云服务、Docker,SaaS 的普及,越来越多的企业开始选择 Hosted CI,也就是托管型持续集成系统。

另外,在选择合适的持续集成服务时,还需要考量系统的灵活度以适应公司不同阶段的开发测试需求。
 
选择持续集成系统只是持续集成应用的其中一步,还需要建立合适的持续集成文化比如代码质量管控、测试文化等。做好持续集成,可为持续交付与持续部署打好坚实基础。
 
持续交付
 
持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。持续交付优先于整个产品生命周期的软件部署,建立在高水平自动化持续集成之上。





试想想,如果说等到所有东西都完成了才向下个环节交付,导致所有的问题只能再最后才爆发出来,解决成本巨大甚至无法解决。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中进行更多的自动化测试。如果代码没有问题,可以继续手动部署到生产环境中。当然,持续交付并不是指软件每一个改动都要尽快部署到产品环境中,它指的是任何的代码修改都可以在任何时候实施部署。
 
持续交付的好处:
持续交付和持续集成的优点非常相似:
快速发布。能够应对业务需求,并更快地实现软件价值。编码->测试->上线->交付的频繁迭代周期缩短,同时获得迅速反馈;高质量的软件发布标准。整个交付过程标准化、可重复、可靠,整个交付过程进度可视化,方便团队人员了解项目成熟度;更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少浪费。
 
持续部署
持续部署是指当交付的代码通过评审之后,自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着,所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。





为什么说持续部署是理想的工作流程?

“开发人员提交代码,持续集成服务器获取代码,执行单元测试,根据测试结果决定是否部署到预演环境,如果成功部署到预演环境,进行整体验收测试,如果测试通过,自动部署到产品环境,全程自动化高效运转。”


实际上,产品在从需求到部署的过程中,会经历若干种不同的环境,例如 QA 环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理,产品在不同环 境中的具体部署,状况是比较非常复杂的,从头到尾地全自动持续部署的确困难。那么,如果能做到持续交付,保证代码在模拟环境没问题,也许团队成员做到真正的心理有数。
 
持续部署的优点:
持续部署主要好处是,可以相对独立地部署新的功能,并能快速地收集真实用户的反馈。

“You build it, you run it”,这是 Amazon 一年可以完成 5000 万次部署,平均每个工程师每天部署超过 50 次的核心秘籍。

 
最后
「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」提供了一个优秀的 DevOps 环境,对于整个团队来说,好处与挑战并行。无论如何,频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。
 

分享阅读链接:http://www.jianshu.com/p/2c6ebe34744a
來源:简书 查看全部
经常会听到持续集成,持续交付,持续部署,三者究竟是什么,有何联系和区别呢?
devops-workfollow.png

假如把开发工作流程分为以下几个阶段:


编码 ---> 构建 ---> 集成 ---> 测试 ---> 交付 ---> 部署


正如你在上图中看到,「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期。
 
持续集成
持续集成是指软件个人研发的部分向软件整体部分交付,频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程(XP),是 XP 最初的 12 种实践之一。
CI.png

CI 需要具备这些:
  • 全面的自动化测试: 这是实践持续集成&持续部署的基础,同时,选择合适的自动化测试工具也极其重要;
  • 灵活的基础设施: 容器,虚拟机的存在让开发人员和 QA 人员不必再大费周折;
  • 版本控制工具: 如 Git,CVS,SVN 等;
  • 自动化的构建和软件发布流程的工具,如 Jenkins,flow.ci;
  • 反馈机制: 如构建/测试的失败,可以快速地反馈到相关负责人,以尽快解决达到一个更稳定的版本。

持续集成的优点:
  • “快速失败”,在对产品没有风险的情况下进行测试,并快速响应;
  • 最大限度地减少风险,降低修复错误代码的成本;
  • 将重复性的手工流程自动化,让工程师更加专注于代码;
  • 保持频繁部署,快速生成可部署的软件;
  • 提高项目的能见度,方便团队成员了解项目的进度和成熟度;
  • 增强开发人员对软件产品的信心,帮助建立更好的工程师文化。

 
持续集成,该从何入手
最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统,关键在于团队运行的基础设施,团队对持续集成系统的资源投入力度。

对比一下私有部署和托管型持续集成系统,或许能帮助你更好地做出选择。
Self Hosted CI 指的是将软件部署在公司的机房或内网中,需要提供多台服务器来完成 CI 系统的运转,同时需要对不同机器之间进行环境配置。比如Maven 或 Gradle 或 Jenkins ,他们的特点是自由开源,且文档支持广泛。优点在于对构建环境有完全的控制权,能够实现完全定制。但需要搭建环境和配置、维护成本高,需要买专门的机器,花费较多人力物力且更新迁移风险高;

Hosted CI 指的是由 SaaS 型的 CI 服务,全程在线进行构建配置,不需要考虑装机器,装软件,环境搭建等成本。常见的有 CircleCI,Codeship 和 TravisCI 等,还有国内最新的持续集成服务——flow.ci 。SaaS 型的 CI 的特点在于无需额外机器,几分钟就可以用起来。可以根据你的需要动态调度资源。省时,省心,省力。
 
整体而言,Jenkins 过去一直是大部分公司的选择,但这个现象正在发生改变,随着公有云服务、Docker,SaaS 的普及,越来越多的企业开始选择 Hosted CI,也就是托管型持续集成系统。

另外,在选择合适的持续集成服务时,还需要考量系统的灵活度以适应公司不同阶段的开发测试需求。
 
选择持续集成系统只是持续集成应用的其中一步,还需要建立合适的持续集成文化比如代码质量管控、测试文化等。做好持续集成,可为持续交付与持续部署打好坚实基础。
 
持续交付
 
持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。持续交付优先于整个产品生命周期的软件部署,建立在高水平自动化持续集成之上。
CD.png


试想想,如果说等到所有东西都完成了才向下个环节交付,导致所有的问题只能再最后才爆发出来,解决成本巨大甚至无法解决。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中进行更多的自动化测试。如果代码没有问题,可以继续手动部署到生产环境中。当然,持续交付并不是指软件每一个改动都要尽快部署到产品环境中,它指的是任何的代码修改都可以在任何时候实施部署。
 
持续交付的好处:
持续交付和持续集成的优点非常相似:
  • 快速发布。能够应对业务需求,并更快地实现软件价值。
  • 编码->测试->上线->交付的频繁迭代周期缩短,同时获得迅速反馈;
  • 高质量的软件发布标准。整个交付过程标准化、可重复、可靠,
  • 整个交付过程进度可视化,方便团队人员了解项目成熟度;
  • 更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少浪费。

 
持续部署
持续部署是指当交付的代码通过评审之后,自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着,所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。
CR.png


为什么说持续部署是理想的工作流程?

“开发人员提交代码,持续集成服务器获取代码,执行单元测试,根据测试结果决定是否部署到预演环境,如果成功部署到预演环境,进行整体验收测试,如果测试通过,自动部署到产品环境,全程自动化高效运转。”



实际上,产品在从需求到部署的过程中,会经历若干种不同的环境,例如 QA 环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理,产品在不同环 境中的具体部署,状况是比较非常复杂的,从头到尾地全自动持续部署的确困难。那么,如果能做到持续交付,保证代码在模拟环境没问题,也许团队成员做到真正的心理有数。
 
持续部署的优点:
持续部署主要好处是,可以相对独立地部署新的功能,并能快速地收集真实用户的反馈。


“You build it, you run it”,这是 Amazon 一年可以完成 5000 万次部署,平均每个工程师每天部署超过 50 次的核心秘籍。


 
最后
「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」提供了一个优秀的 DevOps 环境,对于整个团队来说,好处与挑战并行。无论如何,频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。
 


分享阅读链接:http://www.jianshu.com/p/2c6ebe34744a
來源:简书


VMware Workspace ONE为企业搭建数字化工作空间

OT学习平台 发表了文章 • 0 个评论 • 228 次浏览 • 2017-10-31 16:55 • 来自相关话题

在移动及云计算时代,企业员工的工作方式以及所使用的终端办公设备发生了巨大的变化,同时也面临着一个难题:能提供高效使用移动设备的可选解决方案不仅数量有限,而且只能在身份管理、设备管理与应用交付方案的单一产品之间做出选择。








VMware Workspace ONE专为提供整合设备管理、应用交付以及身份管理的数字化工作空间而设计。

它将多种优势集中在单一移动平台上,帮助企业IT部门为员工交付关键业务资源,并进行安全管理,支持终端用户实现消费级简单访问。

统一企业应用商店






通过AirWatch与Apple Volume Purchase Program(VPP)集成,可批量购买应用程序。AirWatch 通过与 Apple VPP (Volume Purchase Program) 和 Windows Store for Business 的集成来提供软件许可证管理。

统一身份管理






企业应用的身份管理依然面临着诸如:每个应用都要求有一套用户身份、用户需要记忆多个用户帐号、遗留帐号没有跟AD相集成等难题,Workspace ONE可以对身份进行统一管理,避免空间的浪费。

完善的完全保护机制






VMware的Workspace ONE平台将策略实施重新掌握在IT的手中,同时为用户提供灵活的隐私级别的服务,且无需记住登录或使用公司提供的机器。 SDDC和混合云实现了政策控制和灵活性的混合,为Workspace ONE平台的关键特性奠定了基础。

Workspace ONE是市场上唯一可以在整个堆栈中提供安全和管理的集成解决方案。

统一端点管理

Workspace ONE利用业界领先的EMM管理技术+传统的PC管理功能,管理各种Windows 10设备。AirWatch汇集了EMM和传统方法的最佳选择。完整的管理生命周期,从部署开始、管理设备和应用程序,实施安全性以及启用IT和最终用户。

设备调配

不再是刷系统镜像

登录到云端的Azure AD使用AirWatch来注册设备,开箱即用的用户体验 (开机可用就绪)。

配置系统策略

空中配置设备

安装或删除应用设置各种系统配置 (email、VPN、Wi-Fi……) 配置IT策略 (passwords、OS限制……)。

管理操作系统更新

告别 “Patch Tuesdays”

跟最新的Windows更新保持一致,管理安全和新特性更新安排系统维护窗口。

数字化工作空间不仅帮助企业IT部门实现更加高效且轻松的管理用户、设备与应用,它为业务部门构建与再建业务流程提供了一个安全且强大的平台,支持用户的移动业务能够更加有效地参与市场竞争。

想了解更多?敬请关注11月2日14 : 00“VMware——拥抱数字化工作空间”直播活动,听大咖与您分享,Workspace ONE如何为企业打造不一样的数字空间。

看直播·赢好礼

VR3D眼镜、手机特效镜头、硬盘包

等您来拿

直播间地址:“VMware——拥抱数字化工作空间” 查看全部
在移动及云计算时代,企业员工的工作方式以及所使用的终端办公设备发生了巨大的变化,同时也面临着一个难题:能提供高效使用移动设备的可选解决方案不仅数量有限,而且只能在身份管理、设备管理与应用交付方案的单一产品之间做出选择。


数字化工作空间1.png



VMware Workspace ONE专为提供整合设备管理、应用交付以及身份管理的数字化工作空间而设计。

它将多种优势集中在单一移动平台上,帮助企业IT部门为员工交付关键业务资源,并进行安全管理,支持终端用户实现消费级简单访问。

统一企业应用商店

数字化工作空间2.png


通过AirWatch与Apple Volume Purchase Program(VPP)集成,可批量购买应用程序。AirWatch 通过与 Apple VPP (Volume Purchase Program) 和 Windows Store for Business 的集成来提供软件许可证管理。

统一身份管理

数字化工作空间3.png


企业应用的身份管理依然面临着诸如:每个应用都要求有一套用户身份、用户需要记忆多个用户帐号、遗留帐号没有跟AD相集成等难题,Workspace ONE可以对身份进行统一管理,避免空间的浪费。

完善的完全保护机制

数字化工作空间4.png


VMware的Workspace ONE平台将策略实施重新掌握在IT的手中,同时为用户提供灵活的隐私级别的服务,且无需记住登录或使用公司提供的机器。 SDDC和混合云实现了政策控制和灵活性的混合,为Workspace ONE平台的关键特性奠定了基础。

Workspace ONE是市场上唯一可以在整个堆栈中提供安全和管理的集成解决方案。

统一端点管理

Workspace ONE利用业界领先的EMM管理技术+传统的PC管理功能,管理各种Windows 10设备。AirWatch汇集了EMM和传统方法的最佳选择。完整的管理生命周期,从部署开始、管理设备和应用程序,实施安全性以及启用IT和最终用户。

设备调配

不再是刷系统镜像

登录到云端的Azure AD使用AirWatch来注册设备,开箱即用的用户体验 (开机可用就绪)。

配置系统策略

空中配置设备

安装或删除应用设置各种系统配置 (email、VPN、Wi-Fi……) 配置IT策略 (passwords、OS限制……)。

管理操作系统更新

告别 “Patch Tuesdays”

跟最新的Windows更新保持一致,管理安全和新特性更新安排系统维护窗口。

数字化工作空间不仅帮助企业IT部门实现更加高效且轻松的管理用户、设备与应用,它为业务部门构建与再建业务流程提供了一个安全且强大的平台,支持用户的移动业务能够更加有效地参与市场竞争。

想了解更多?敬请关注11月2日14 : 00“VMware——拥抱数字化工作空间”直播活动,听大咖与您分享,Workspace ONE如何为企业打造不一样的数字空间。

看直播·赢好礼

VR3D眼镜、手机特效镜头、硬盘包

等您来拿

直播间地址:“VMware——拥抱数字化工作空间

Apache Solr/Lucene 0Day远程代码执行漏洞安全预警

OS小编 发表了文章 • 0 个评论 • 240 次浏览 • 2017-10-20 22:07 • 来自相关话题

近日,Apache Solr/Lucene修复了一个0-day漏洞,该漏洞可能导致运程代码执行、信息泄露,危害严重。请及时检查您所使用的Apache Solr是否受影响,并采取安全防御措施。
 
影响范围:

Solr 5.5.0 to 5.5.4

Solr 6.0.0 to 6.6.1

Solr 7.0.0 to 7.0.1

修复方案:

升级到官方提供的安全修复版本:

Solr 6.6.2

Solr 7.1.0

漏洞详情:
CVE-2017-12629:Apache Solr存在XXE和RCE漏洞:
lucene xml解析器没有明确禁止doctype 外部实体的声明,黑客可通过构造恶意的XML请求来读取服务器任意文件,导致信息泄露。Apache Solr“RunExecutableListener”类可以通过恶意的请求来执行任意操作,导致服务器被控制。
 
参考链接:
https://issues.apache.org/jira/browse/SOLR-11482  
https://issues.apache.org/jira/browse/SOLR-11477   查看全部
近日,Apache Solr/Lucene修复了一个0-day漏洞,该漏洞可能导致运程代码执行、信息泄露,危害严重。请及时检查您所使用的Apache Solr是否受影响,并采取安全防御措施。
 
影响范围:


Solr 5.5.0 to 5.5.4

Solr 6.0.0 to 6.6.1

Solr 7.0.0 to 7.0.1


修复方案:


升级到官方提供的安全修复版本:

Solr 6.6.2

Solr 7.1.0


漏洞详情:
CVE-2017-12629:Apache Solr存在XXE和RCE漏洞:
  1. lucene xml解析器没有明确禁止doctype 外部实体的声明,黑客可通过构造恶意的XML请求来读取服务器任意文件,导致信息泄露。
  2. Apache Solr“RunExecutableListener”类可以通过恶意的请求来执行任意操作,导致服务器被控制。

 
参考链接:
https://issues.apache.org/jira/browse/SOLR-11482  
https://issues.apache.org/jira/browse/SOLR-11477  

CentOS系统自动下载RPM包及其所有依赖的包

Ansible 发表了文章 • 0 个评论 • 331 次浏览 • 2017-10-08 19:15 • 来自相关话题

前几天我尝试去创建一个仅包含我们经常在 CentOS 7 下使用的软件的本地仓库。当然,我们可以使用 curl 或者 wget 下载任何软件包,然而这些命令并不能下载要求的依赖软件包。你必须去花一些时间而且手动的去寻找和下载被安装的软件所依赖的软件包。然而,我们并不是必须这样。在这个简短的教程中,我将会带领你以两种方式下载软件包及其所有依赖包。我已经在 CentOS 7 下进行了测试,不过这些相同的步骤或许在其他基于 RPM 管理系统的发行版上也可以工作,例如 RHEL,Fedora 和 Scientific Linux。
 

方法1利用"Downloadonly"插件下载 RPM 软件包及其所有依赖包

我们可以通过 yum 命令的 “Downloadonly” 插件下载 RPM 软件包及其所有依赖包, 为了安装 Downloadonly 插件,以 root 身份运行以下命令:
yum install yum-plugin-downloadonly现在,运行以下命令去下载一个 RPM 软件包
yum install --downloadonly <package-name>默认情况下,这个命令将会下载并把软件包保存到 /var/cache/yum/ 的 rhel-{arch}-channel/packageslocation 目录,不过,你也可以下载和保存软件包到任何位置,你可以通过 –downloaddir 选项来指定。
yum install --downloadonly --downloaddir=<directory> <package-name>例子:
yum install --downloadonly --downloaddir=/root/mypackages/ httpd终端输出:
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: centos.excellmedia.net
* epel: epel.mirror.angkasa.id
* extras: centos.excellmedia.net
* updates: centos.excellmedia.net
Resolving Dependencies
--> Running transaction check
---> Package httpd.x86_64 0:2.4.6-40.el7.centos.4 will be installed
--> Processing Dependency: httpd-tools = 2.4.6-40.el7.centos.4 for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Processing Dependency: /etc/mime.types for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Running transaction check
---> Package apr.x86_64 0:1.4.8-3.el7 will be installed
---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed
---> Package httpd-tools.x86_64 0:2.4.6-40.el7.centos.4 will be installed
---> Package mailcap.noarch 0:2.1.41-2.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
=======================================================================================================================================
Package Arch Version Repository Size
=======================================================================================================================================
Installing:
httpd x86_64 2.4.6-40.el7.centos.4 updates 2.7 M
Installing for dependencies:
apr x86_64 1.4.8-3.el7 base 103 k
apr-util x86_64 1.5.2-6.el7 base 92 k
httpd-tools x86_64 2.4.6-40.el7.centos.4 updates 83 k
mailcap noarch 2.1.41-2.el7 base 31 k
Transaction Summary
=======================================================================================================================================
Install 1 Package (+4 Dependent packages)
Total download size: 3.0 M
Installed size: 10 M
Background downloading packages, then exiting:
(1/5): apr-1.4.8-3.el7.x86_64.rpm | 103 kB 00:00:01
(2/5): apr-util-1.5.2-6.el7.x86_64.rpm | 92 kB 00:00:01
(3/5): mailcap-2.1.41-2.el7.noarch.rpm | 31 kB 00:00:01
(4/5): httpd-tools-2.4.6-40.el7.centos.4.x86_64.rpm | 83 kB 00:00:01
(5/5): httpd-2.4.6-40.el7.centos.4.x86_64.rpm | 2.7 MB 00:00:09
---------------------------------------------------------------------------------------------------------------------------------------
Total 331 kB/s | 3.0 MB 00:00:09
exiting because "Download Only" specified



现在去你指定的目录位置下,你将会看到那里有下载好的软件包和依赖的软件。在我这种情况下,我已经把软件包下载到 /root/mypackages/ 目录下。
 
让我们来查看一下内容:
ls /root/mypackages/样本输出:
apr-1.4.8-3.el7.x86_64.rpm
apr-util-1.5.2-6.el7.x86_64.rpm
httpd-2.4.6-40.el7.centos.4.x86_64.rpm
httpd-tools-2.4.6-40.el7.centos.4.x86_64.rpm
mailcap-2.1.41-2.el7.noarch.rpm



正如你在上面输出所看到的, httpd软件包已经被依据所有依赖性下载完成了 。
 
请注意,这个插件适用于 yum install/yum update, 但是并不适用于 yum groupinstall。默认情况下,这个插件将会下载仓库中最新可用的软件包。然而你可以通过指定版本号来下载某个特定的软件版本。

例子:
yum install --downloadonly --downloaddir=/root/mypackages/ httpd-2.2.6-40.el7此外,你也可以如下一次性下载多个包:
yum install --downloadonly --downloaddir=/root/mypackages/ httpd vsftpd

方法 2 使用 "Yumdownloader"工具来下载 RPM 软件包及其所有依赖包

“Yumdownloader” 是一款简单,但是却十分有用的命令行工具,它可以一次性下载任何 RPM 软件包及其所有依赖包。

以 root 身份运行如下命令安装 “Yumdownloader” 工具。
yum install yum-utils一旦安装完成,运行如下命令去下载一个软件包,例如 httpd:
yumdownloader httpd为了根据所有依赖性下载软件包,我们使用 --resolve 参数:
yumdownloader --resolve httpd默认情况下,Yumdownloader 将会下载软件包到当前工作目录下。

为了将软件下载到一个特定的目录下,我们使用 --destdir 参数:
yumdownloader --resolve --destdir=/root/mypackages/ httpd或者
yumdownloader --resolve --destdir /root/mypackages/ httpd终端输出:
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: centos.excellmedia.net
* epel: epel.mirror.angkasa.id
* extras: centos.excellmedia.net
* updates: centos.excellmedia.net
--> Running transaction check
---> Package httpd.x86_64 0:2.4.6-40.el7.centos.4 will be installed
--> Processing Dependency: httpd-tools = 2.4.6-40.el7.centos.4 for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Processing Dependency: /etc/mime.types for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Running transaction check
---> Package apr.x86_64 0:1.4.8-3.el7 will be installed
---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed
---> Package httpd-tools.x86_64 0:2.4.6-40.el7.centos.4 will be installed
---> Package mailcap.noarch 0:2.1.41-2.el7 will be installed
--> Finished Dependency Resolution
(1/5): apr-util-1.5.2-6.el7.x86_64.rpm | 92 kB 00:00:01
(2/5): mailcap-2.1.41-2.el7.noarch.rpm | 31 kB 00:00:02
(3/5): apr-1.4.8-3.el7.x86_64.rpm | 103 kB 00:00:02
(4/5): httpd-tools-2.4.6-40.el7.centos.4.x86_64.rpm | 83 kB 00:00:03
(5/5): httpd-2.4.6-40.el7.centos.4.x86_64.rpm | 2.7 MB 00:00:19



让我们确认一下软件包是否被下载到我们指定的目录下:
ls /root/mypackages/终端输出:
apr-1.4.8-3.el7.x86_64.rpm
apr-util-1.5.2-6.el7.x86_64.rpm
httpd-2.4.6-40.el7.centos.4.x86_64.rpm
httpd-tools-2.4.6-40.el7.centos.4.x86_64.rpm
mailcap-2.1.41-2.el7.noarch.rpm



不像 Downloadonly 插件,Yumdownload 可以下载一组相关的软件包。
yumdownloader "@Development Tools" --resolve --destdir /root/mypackages/在我看来,我喜欢 Yumdownloader 更胜于 Yum 的 Downloadonly 插件。但是,两者都是十分简单易懂而且可以完成相同的工作。

这就是今天所有的内容,如果你觉得这份引导教程有用,清在你的社交媒体上面分享一下去让更多的人知道。

阅读分享,英文:https://www.ostechnix.com/download-rpm-package-dependencies-centos/ 中文:https://linux.cn/article-7937-1.html 查看全部
前几天我尝试去创建一个仅包含我们经常在 CentOS 7 下使用的软件的本地仓库。当然,我们可以使用 curl 或者 wget 下载任何软件包,然而这些命令并不能下载要求的依赖软件包。你必须去花一些时间而且手动的去寻找和下载被安装的软件所依赖的软件包。然而,我们并不是必须这样。在这个简短的教程中,我将会带领你以两种方式下载软件包及其所有依赖包。我已经在 CentOS 7 下进行了测试,不过这些相同的步骤或许在其他基于 RPM 管理系统的发行版上也可以工作,例如 RHEL,Fedora 和 Scientific Linux。
 


方法1利用"Downloadonly"插件下载 RPM 软件包及其所有依赖包


我们可以通过 yum 命令的 “Downloadonly” 插件下载 RPM 软件包及其所有依赖包, 为了安装 Downloadonly 插件,以 root 身份运行以下命令:
yum install yum-plugin-downloadonly
现在,运行以下命令去下载一个 RPM 软件包
yum install --downloadonly <package-name>
默认情况下,这个命令将会下载并把软件包保存到 /var/cache/yum/ 的 rhel-{arch}-channel/packageslocation 目录,不过,你也可以下载和保存软件包到任何位置,你可以通过 –downloaddir 选项来指定。
yum install --downloadonly --downloaddir=<directory> <package-name>
例子:
yum install --downloadonly --downloaddir=/root/mypackages/ httpd
终端输出:
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: centos.excellmedia.net
* epel: epel.mirror.angkasa.id
* extras: centos.excellmedia.net
* updates: centos.excellmedia.net
Resolving Dependencies
--> Running transaction check
---> Package httpd.x86_64 0:2.4.6-40.el7.centos.4 will be installed
--> Processing Dependency: httpd-tools = 2.4.6-40.el7.centos.4 for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Processing Dependency: /etc/mime.types for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Running transaction check
---> Package apr.x86_64 0:1.4.8-3.el7 will be installed
---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed
---> Package httpd-tools.x86_64 0:2.4.6-40.el7.centos.4 will be installed
---> Package mailcap.noarch 0:2.1.41-2.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
=======================================================================================================================================
Package Arch Version Repository Size
=======================================================================================================================================
Installing:
httpd x86_64 2.4.6-40.el7.centos.4 updates 2.7 M
Installing for dependencies:
apr x86_64 1.4.8-3.el7 base 103 k
apr-util x86_64 1.5.2-6.el7 base 92 k
httpd-tools x86_64 2.4.6-40.el7.centos.4 updates 83 k
mailcap noarch 2.1.41-2.el7 base 31 k
Transaction Summary
=======================================================================================================================================
Install 1 Package (+4 Dependent packages)
Total download size: 3.0 M
Installed size: 10 M
Background downloading packages, then exiting:
(1/5): apr-1.4.8-3.el7.x86_64.rpm | 103 kB 00:00:01
(2/5): apr-util-1.5.2-6.el7.x86_64.rpm | 92 kB 00:00:01
(3/5): mailcap-2.1.41-2.el7.noarch.rpm | 31 kB 00:00:01
(4/5): httpd-tools-2.4.6-40.el7.centos.4.x86_64.rpm | 83 kB 00:00:01
(5/5): httpd-2.4.6-40.el7.centos.4.x86_64.rpm | 2.7 MB 00:00:09
---------------------------------------------------------------------------------------------------------------------------------------
Total 331 kB/s | 3.0 MB 00:00:09
exiting because "Download Only" specified
httpd.png

现在去你指定的目录位置下,你将会看到那里有下载好的软件包和依赖的软件。在我这种情况下,我已经把软件包下载到 /root/mypackages/ 目录下。
 
让我们来查看一下内容:
ls /root/mypackages/
样本输出:
apr-1.4.8-3.el7.x86_64.rpm
apr-util-1.5.2-6.el7.x86_64.rpm
httpd-2.4.6-40.el7.centos.4.x86_64.rpm
httpd-tools-2.4.6-40.el7.centos.4.x86_64.rpm
mailcap-2.1.41-2.el7.noarch.rpm
lsoutppt.png

正如你在上面输出所看到的, httpd软件包已经被依据所有依赖性下载完成了 。
 
请注意,这个插件适用于 yum install/yum update, 但是并不适用于 yum groupinstall。默认情况下,这个插件将会下载仓库中最新可用的软件包。然而你可以通过指定版本号来下载某个特定的软件版本。

例子:
yum install --downloadonly --downloaddir=/root/mypackages/ httpd-2.2.6-40.el7
此外,你也可以如下一次性下载多个包:
yum install --downloadonly --downloaddir=/root/mypackages/ httpd vsftpd


方法 2 使用 "Yumdownloader"工具来下载 RPM 软件包及其所有依赖包


“Yumdownloader” 是一款简单,但是却十分有用的命令行工具,它可以一次性下载任何 RPM 软件包及其所有依赖包。

以 root 身份运行如下命令安装 “Yumdownloader” 工具。
yum install yum-utils
一旦安装完成,运行如下命令去下载一个软件包,例如 httpd:
yumdownloader httpd
为了根据所有依赖性下载软件包,我们使用 --resolve 参数:
yumdownloader --resolve httpd
默认情况下,Yumdownloader 将会下载软件包到当前工作目录下。

为了将软件下载到一个特定的目录下,我们使用 --destdir 参数:
yumdownloader --resolve --destdir=/root/mypackages/ httpd
或者
yumdownloader --resolve --destdir /root/mypackages/ httpd
终端输出:
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: centos.excellmedia.net
* epel: epel.mirror.angkasa.id
* extras: centos.excellmedia.net
* updates: centos.excellmedia.net
--> Running transaction check
---> Package httpd.x86_64 0:2.4.6-40.el7.centos.4 will be installed
--> Processing Dependency: httpd-tools = 2.4.6-40.el7.centos.4 for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Processing Dependency: /etc/mime.types for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.4.x86_64
--> Running transaction check
---> Package apr.x86_64 0:1.4.8-3.el7 will be installed
---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed
---> Package httpd-tools.x86_64 0:2.4.6-40.el7.centos.4 will be installed
---> Package mailcap.noarch 0:2.1.41-2.el7 will be installed
--> Finished Dependency Resolution
(1/5): apr-util-1.5.2-6.el7.x86_64.rpm | 92 kB 00:00:01
(2/5): mailcap-2.1.41-2.el7.noarch.rpm | 31 kB 00:00:02
(3/5): apr-1.4.8-3.el7.x86_64.rpm | 103 kB 00:00:02
(4/5): httpd-tools-2.4.6-40.el7.centos.4.x86_64.rpm | 83 kB 00:00:03
(5/5): httpd-2.4.6-40.el7.centos.4.x86_64.rpm | 2.7 MB 00:00:19
yumdownload.png

让我们确认一下软件包是否被下载到我们指定的目录下:
ls /root/mypackages/
终端输出:
apr-1.4.8-3.el7.x86_64.rpm
apr-util-1.5.2-6.el7.x86_64.rpm
httpd-2.4.6-40.el7.centos.4.x86_64.rpm
httpd-tools-2.4.6-40.el7.centos.4.x86_64.rpm
mailcap-2.1.41-2.el7.noarch.rpm
output.png

不像 Downloadonly 插件,Yumdownload 可以下载一组相关的软件包。
yumdownloader "@Development Tools" --resolve --destdir /root/mypackages/
在我看来,我喜欢 Yumdownloader 更胜于 Yum 的 Downloadonly 插件。但是,两者都是十分简单易懂而且可以完成相同的工作。

这就是今天所有的内容,如果你觉得这份引导教程有用,清在你的社交媒体上面分享一下去让更多的人知道。

阅读分享,英文:https://www.ostechnix.com/download-rpm-package-dependencies-centos/ 中文:https://linux.cn/article-7937-1.html

访问服务器为什么需要智能身份识别

OT学习平台 发表了文章 • 0 个评论 • 226 次浏览 • 2017-09-28 17:11 • 来自相关话题

早期防火墙是通过IP地址或端口来控制用户资源访问的,但通过“IP地址+端口”的方式很难控制及识别用户,从而存在安全隐患,而智能身份识别能够识别用户和用户所使用的计算机,进而可以对用户的网络行为进行访问控制,最终达到安全的目的。

Checkpoint防火墙主要是通过以下几种方式获取用户身份

1、AD query

通过微软Ad server来获得用户的身份信息、适用于大型网络,用户较多的环境。结合AD域只针对用户的AD记录来进行认证,不再针对IP地址一类信息。

(1)    安全网关从AD服务器上获得安全事件日志;
(2)    用户登录到域;
(3)    域服务器发送安全事件日志给安全网关,安全网关获取到用户的IP和用户相关信息(如用户的域信息,计算机名和源IP地址);
(4)    用户要访问Internet;
(5)    安全网关确认用户身份后,根据策略决定是否允许用户访问Internet。

2、通过浏览器捕获身份

使用基于浏览器捕获身份认证信息。适用于非微软AD用户,通过浏览器来访问web资源。
流程如下:
(1)    用户从外部发起到datacenter的访问;
(2)    防火墙IA模块没有识别出用户,然后重定向用户的访问至Web portal界面;
(3)    用户输入自己的认证信息:可以使AD/LDAP/RADIUS等;
(4)    认证信息被发送至防火墙,之后防火墙通过后边所连接的AD server来返回用户的认证结果;
(5)    如果允许,则放通访问;
(6)    如果不允许,则不能通过访问。

3、通过agent获得用户身份

基于agent的认证类型有两种:

(1)    Endpoint Identity Agent:安装在用户PC上。
(2)    Terminal Servers Endpoint Identity Agent:安装在虚拟桌面系统中,能够识别同一IP源地址的不同用户。

认证流程如下:
(1)    用户发起到datacenter访问;
(2)    启用IA的安全网关向用户弹出web认证页面;
(3)    用户在web界面中点击下载agent的链接;
(4)    用户下载并安装Endpoint Identity Agent;
(5)    用户通过这个agent去连接安全网关;
(6)    用户认证通过,安全网关根据安全策略决定是否发起用户到目的地址的访问。

相同之处:

都有一个安全的身份识别的过程,都需要流量经过防火墙,然后通过防火墙来结合(AD域)来达到用户识别的目的。

不同之处:

有的是用浏览器来获取用户身份,而有的是用客户端来识别,还有结合浏览器和AD域来识别。

学习完整Check point智能身份识别课程,请点击“Check point智能身份识别” 查看全部
早期防火墙是通过IP地址或端口来控制用户资源访问的,但通过“IP地址+端口”的方式很难控制及识别用户,从而存在安全隐患,而智能身份识别能够识别用户和用户所使用的计算机,进而可以对用户的网络行为进行访问控制,最终达到安全的目的。

Checkpoint防火墙主要是通过以下几种方式获取用户身份

1、AD query

通过微软Ad server来获得用户的身份信息、适用于大型网络,用户较多的环境。结合AD域只针对用户的AD记录来进行认证,不再针对IP地址一类信息。

(1)    安全网关从AD服务器上获得安全事件日志;
(2)    用户登录到域;
(3)    域服务器发送安全事件日志给安全网关,安全网关获取到用户的IP和用户相关信息(如用户的域信息,计算机名和源IP地址);
(4)    用户要访问Internet;
(5)    安全网关确认用户身份后,根据策略决定是否允许用户访问Internet。

2、通过浏览器捕获身份

使用基于浏览器捕获身份认证信息。适用于非微软AD用户,通过浏览器来访问web资源。
流程如下:
(1)    用户从外部发起到datacenter的访问;
(2)    防火墙IA模块没有识别出用户,然后重定向用户的访问至Web portal界面;
(3)    用户输入自己的认证信息:可以使AD/LDAP/RADIUS等;
(4)    认证信息被发送至防火墙,之后防火墙通过后边所连接的AD server来返回用户的认证结果;
(5)    如果允许,则放通访问;
(6)    如果不允许,则不能通过访问。

3、通过agent获得用户身份

基于agent的认证类型有两种:


(1)    Endpoint Identity Agent:安装在用户PC上。
(2)    Terminal Servers Endpoint Identity Agent:安装在虚拟桌面系统中,能够识别同一IP源地址的不同用户。

认证流程如下:
(1)    用户发起到datacenter访问;
(2)    启用IA的安全网关向用户弹出web认证页面;
(3)    用户在web界面中点击下载agent的链接;
(4)    用户下载并安装Endpoint Identity Agent;
(5)    用户通过这个agent去连接安全网关;
(6)    用户认证通过,安全网关根据安全策略决定是否发起用户到目的地址的访问。


相同之处:

都有一个安全的身份识别的过程,都需要流量经过防火墙,然后通过防火墙来结合(AD域)来达到用户识别的目的。

不同之处:

有的是用浏览器来获取用户身份,而有的是用客户端来识别,还有结合浏览器和AD域来识别。

学习完整Check point智能身份识别课程,请点击“Check point智能身份识别

Postfix小技巧和故障诊断命令

Ansible 发表了文章 • 0 个评论 • 267 次浏览 • 2017-09-03 23:27 • 来自相关话题

下面列举出来的一些小技巧在邮件管理员的日常中会经常用到,如果有什么错误,请留言交流。
 
打印邮件队列:# postqueue –p# mailq
如果队列数较大可以配合tail查看:# mailq | tail
刷新队列:# postqueue -f
立即为队列中domain.com的域名的邮件发送:# postqueue -s domain.com
删除队列中所有邮件:# postsuper -d ALL
删除一个特定的信息:# postsuper -d messageid
重新发送特定的邮件:# postfix -r msgid
查看postfix邮件版本:# postconf -d mail_version
mail_version = 2.6.6

英文原文: https://techarena51.com/blog/postfix-configuration-and-explanation-of-parameters/  查看全部
下面列举出来的一些小技巧在邮件管理员的日常中会经常用到,如果有什么错误,请留言交流。
 
打印邮件队列:
# postqueue –p
# mailq

如果队列数较大可以配合tail查看:
# mailq | tail

刷新队列:
# postqueue -f

立即为队列中domain.com的域名的邮件发送:
# postqueue -s domain.com

删除队列中所有邮件:
# postsuper -d ALL

删除一个特定的信息:
# postsuper -d messageid

重新发送特定的邮件:
# postfix -r msgid

查看postfix邮件版本:
# postconf -d mail_version
mail_version = 2.6.6


英文原文: https://techarena51.com/blog/postfix-configuration-and-explanation-of-parameters/ 


NetSarang旗下XShell和Xmanager多款软件被植入后门

OS小编 发表了文章 • 0 个评论 • 244 次浏览 • 2017-08-15 16:20 • 来自相关话题

近日,境内外多家安全公司爆料称NetSarang旗下Xmanager和Xshell等产品的多个版本被植入后门代码,由于相关软件在国内程序开发和运维人员中被广泛使用,可能导致大量用户服务器账号密码泄露。请及时检查您所使用的版本是否受影响,并采取安全防御措施。
 

影响范围

使用了nssock2.dll 5.0.0.26的版本会受到影响,其中包括:
 Xmanager Enterprise 5.0 Build 1232 Xmanager 5.0 Build 1045 Xshell 5.0 Build 1322 Xshell 5.0 Build 1325 Xftp 5.0 Build 1218 Xlpd 5.0 Build 1220
 

修复方案

 1、从官网下载最新版本进行升级:https://www.netsarang.com/download/software.html  ;
 
2、排查2017年的DNS访问日志,如出现如下子域名相关访问记录,建议修改对应员工使用过Xmanager 、XShell、Xftp等相关的登录账号密码:
vwrcbohspufip.comribotqtonut.comnylalobghyhirgh.comjkvmdmjyfcvkf.combafyvoruzgjitwr.comxmponmzmxkxkh.comtczafklirkl.com
 

漏洞详情

某安全公司发现NetSarang的Xmanager, Xshell, Xftp, Xlpd等产品中,发布的nssock2.dll模块中存在恶意代码远程漏洞,存在后门的XShell等程序会在启动时发起大量请求DNS域名请求,并根据使用者系统时间生成不同的请求链接。有媒体报道,带后门的Xshell会向服务器传输敏感信息。
 
参考链接:https://www.netsarang.com/news/security_exploit_in_july_18_2017_build.html  。 查看全部
近日,境内外多家安全公司爆料称NetSarang旗下Xmanager和Xshell等产品的多个版本被植入后门代码,由于相关软件在国内程序开发和运维人员中被广泛使用,可能导致大量用户服务器账号密码泄露。请及时检查您所使用的版本是否受影响,并采取安全防御措施。
 


影响范围


使用了nssock2.dll 5.0.0.26的版本会受到影响,其中包括:
  •  Xmanager Enterprise 5.0 Build 1232
  •  Xmanager 5.0 Build 1045
  •  Xshell 5.0 Build 1322
  •  Xshell 5.0 Build 1325
  •  Xftp 5.0 Build 1218
  •  Xlpd 5.0 Build 1220

 


修复方案


 1、从官网下载最新版本进行升级:https://www.netsarang.com/download/software.html  ;
 
2、排查2017年的DNS访问日志,如出现如下子域名相关访问记录,建议修改对应员工使用过Xmanager 、XShell、Xftp等相关的登录账号密码:
  • vwrcbohspufip.com
  • ribotqtonut.com
  • nylalobghyhirgh.com
  • jkvmdmjyfcvkf.com
  • bafyvoruzgjitwr.com
  • xmponmzmxkxkh.com
  • tczafklirkl.com

 


漏洞详情


某安全公司发现NetSarang的Xmanager, Xshell, Xftp, Xlpd等产品中,发布的nssock2.dll模块中存在恶意代码远程漏洞,存在后门的XShell等程序会在启动时发起大量请求DNS域名请求,并根据使用者系统时间生成不同的请求链接。有媒体报道,带后门的Xshell会向服务器传输敏感信息。
 
参考链接:https://www.netsarang.com/news/security_exploit_in_july_18_2017_build.html  。