mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
fc72ec5840
@ -1,8 +1,11 @@
|
||||
DevOps 如何消除掉 Ranger 社区的瓶颈
|
||||
DevOps 如何消除了 Ranger 社区的瓶颈
|
||||
======
|
||||
|
||||
> 拥抱 DevOps 让 Ranger 成员们变得更灵活、快捷和成为开发者社区更有价值的成员。
|
||||
|
||||
|
||||
|
||||
Visual Studio Application Lifecycle Management（ALM）项目 —— [Ranger][1] 是一个志愿者社区，它提供专业的指导、实践经验、以及开发者社区的漏洞修补解决方案。它创建于 2006 年，作为微软内部社区去 "connect the product group with the field and remove adoption blockers"。 在 2009 时，社区已经有超过 200 位成员，这导致了协作和计划面临很大的挑战，在依赖和手工流程上产生了瓶颈，并导致了开发者社区不断增加的延迟和各种报怨。在 2010 时，计划进一步去扩充包括微软最有价值专家（MVP）在内的分布在全球的社区。
|
||||
Visual Studio 的<ruby>应用周期管理<rt>Application Lifecycle Management</rt></ruby>（ALM）项目 —— [Ranger][1] 是一个志愿者社区，它提供专业的指导、实践经验、以及开发者社区的漏洞修补解决方案。它创建于 2006 年，作为微软内部社区去 “将产品组与大家相连接，并去除推广阻力”。 在 2009 时，社区已经有超过 200 位成员，这导致了协作和计划面临很大的挑战，在依赖和手工流程上产生了瓶颈，并导致了开发者社区不断增加的延迟和各种报怨。在 2010 时，计划进一步去扩充包括微软最有价值专家（MVP）在内的分布在全球的社区。
|
||||
|
||||
这个社区被分割成十几个活跃的团队。每个团队都致力于通过它的生命周期去设计、构建和支持一个指导或处理项目。在以前，团队的瓶颈在团队管理级别上，原因是严格的、瀑布式的流程和高度依赖一个或多个项目经理。在制作、发布和“为什么、做什么、和怎么做”驱动的决定上，项目经理都要介入其中。另外，缺乏一个实时的指标阻止了团队对他们的解决方案效率的监控，以及对来自社区的关于 bug 和常见问题的关注。
|
||||
|
||||
@ -10,21 +13,21 @@ Visual Studio Application Lifecycle Management（ALM）项目 —— [Ranger][1
|
||||
|
||||
### DevOps 去“灭火”
|
||||
|
||||
> "DevOps 是人员、流程、和产品的结合，使我们的最终用户能够持续传递价值。" --[Donovan Brown][2]
|
||||
> “DevOps 是人员、流程和产品的结合，使我们的最终用户能够持续传递价值。” --[Donovan Brown][2]
|
||||
|
||||
为解决这些挑战，社区停止了所有对新项目的冲刺，去探索敏捷实践和新产品。致力于使社区重新活跃起来，为找到促进自治、掌控、和目标的方法，正如在 Daniel H. Pink 的书 —— [Drive][3] 中所说的那样，对僵化的流程和产品进行彻底的改革。
|
||||
为解决这些挑战，社区停止了所有对新项目的冲刺，去探索敏捷实践和新产品。致力于使社区重新活跃起来，为找到促进自治、掌控、和目标的方法，正如在 Daniel H. Pink 的书《[Drive][3]》中所说的那样，对僵化的流程和产品进行彻底的改革。
|
||||
|
||||
> “成熟的自组织、自管理、和跨职能团队，在自治、掌控、和目标上茁壮成长。" --Drive, Daniel H. Pink.
|
||||
> “成熟的自组织、自管理和跨职能团队，在自治、掌控和目标上茁壮成长。" --Drive, Daniel H. Pink.
|
||||
|
||||
从文化开始 —— 人 —— 第一步是去拥抱 DevOps。社区实现了 [Scrum][4] 框架，使用 [kanban][5] 去提升工程化流程，并且通过可视化去提升透明度、意识和最重要的东西 —— 信任。使用自组织团队后，传统的等级制度和指挥系统消失了。自管理促使团队去积极监视和设计它们自己的流程。
|
||||
|
||||
在 2010 年 4 月份，社区再次实施了另外的关键一步，切换并提交它们的文化、流程、以及产品到云上。虽然开放的”为社区而社区“的核心 [解决方案][6] 仍然是指导和补充，但是在开源解决方案（OSS）上大量增加投资去研究和共享 DevOps 转换的成就。
|
||||
在 2010 年 4 月份，社区再次实施了另外的关键一步，切换并提交它们的文化、流程、以及产品到云上。虽然开放的“为社区而社区”的核心 [解决方案][6] 仍然是指导和补充，但是在开源解决方案（OSS）上大量增加投资去研究和共享 DevOps 转换的成就。
|
||||
|
||||
持续集成（CI）和持续交付（CD）使用自动化流水线代替了死板的人工流程。这使得团队在不受来自项目经理的干预的情况下为早期问题和早期应用者部署解决方案。增加遥测技术可以使团队关注他们的解决方案，以及在用户注意到它们之前，检测和处理未知的问题。
|
||||
|
||||
DevOps 转变是一个持续进化的过程，通过实验去探索和验证人、流程、和产品的改革。最新的试验引入了流水线革新，它可以持续提升价值流。自动扫描组件、持续地、以及静默地检查安全、协议、和开源组件的品质。部署环和特性标志允许团队对所有或者特定用户进行更细粒度的控制。
|
||||
DevOps 转变是一个持续进化的过程，通过实验去探索和验证人、流程和产品的改革。最新的试验引入了流水线革新，它可以持续提升价值流。自动扫描组件、持续地以及静默地检查安全、协议和开源组件的品质。部署环和特性标志允许团队对所有或者特定用户进行更细粒度的控制。
|
||||
|
||||
在 2017 年 10 月，社区将大部分的私有版本控制仓库转移到 [GitHub][7] 上。对所有仓库转移所有者和管理职责到 ALM DevOps Rangers 社区，给团队提供自治和机会，去激励更多的社区对开源解决方案作贡献。团队被授权向他们的最终用户交付质量和价值。
|
||||
在 2017 年 10 月，社区将大部分的私有版本控制仓库转移到 [GitHub][7] 上。将所有仓库转移所有者和管理职责到 ALM DevOps Rangers 社区，给团队提供自治和机会，去激励更多的社区对开源解决方案作贡献。团队被授权向他们的最终用户交付质量和价值。
|
||||
|
||||
### 好处和成就
|
||||
|
||||
@ -32,7 +35,7 @@ DevOps 转变是一个持续进化的过程，通过实验去探索和验证人
|
||||
|
||||
下面是从这个转变中观察到的一个列表，排列没有特定的顺序：
|
||||
|
||||
* 自治、掌控、和目标是核心。
|
||||
* 自治、掌控和目标是核心。
|
||||
* 从可触摸的和可迭代的东西开始 —— 避免摊子铺的过大。
|
||||
* 可触摸的和可操作的指标很重要 —— 确保不要掺杂其它东西。
|
||||
* 人（文化）的转变是最具挑战的部分。
|
||||
@ -42,10 +45,22 @@ DevOps 转变是一个持续进化的过程，通过实验去探索和验证人
|
||||
* 使用工程化流程去强化预期行为。
|
||||
|
||||
|
||||
转换变化表：
|
||||
|
||||
转换变化表：~~（致核对：以下是表格，格式转换造成错乱了。）~~
|
||||
|
||||
PAST CURRENT ENVISIONED Branching Servicing and release isolation Feature Master Build Manual and error prone Automated and consistent Issue detection Call from user Proactive telemetry Issue resolution Days to weeks Minutes to days Minutes Planning Detailed design Prototyping and storyboards Program management 2 program managers (PM) 0.25 PM 0.125 PM Release cadence 6 to 12 months 3 to 5 sprints Every sprint Release Manual and error prone Automated and consistent Sprints 1 month 3 weeks Team size 10 to 15 2 to 5 Time to build Hours Seconds Time to release Days Minutes
|
||||
| | 过去 | 当前 | 想象 |
|
||||
|---|------|---------|-----------|
|
||||
| 分支 | 服务于发布隔离 | 特性 | 主分支 |
|
||||
| 构建 |手动且易错 | 自动而一致 | |
|
||||
| 问题检测 | 来自用户 | 主动感知 |
|
||||
| 问题解决 | 几天到几周 | 几分钟到几天 | 几分钟 |
|
||||
| 计划 | 详细的设计 | 原型与故事板 | |
|
||||
| 流程管理 | 2 个流程经理（PM） | 0.25 个 PM | 0.125 个 PM |
|
||||
| 发布终止 | 6 到 12 个月 | 3 到 5 周期 | 每个周期 |
|
||||
| 发布 | 手动且易错 | 自动而一致 ||
|
||||
| 周期 | 1 个月 | 3 周 ||
|
||||
| 团队规模 | 10 到 15 | 2 到 5 ||
|
||||
| 构建时间 | 几小时 | 几秒钟 ||
|
||||
| 发布时间 | 几天 | 几分钟 ||
|
||||
|
||||
但是，我们还没有做完，相反，我们就是一个令人兴奋的、持续不断的、几乎从不结束的转变的一部分。
|
||||
|
||||
@ -57,7 +72,7 @@ via: https://opensource.com/article/17/11/devops-rangers-transformation
|
||||
|
||||
作者：[Willy Schaub][a]
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,5 +1,6 @@
|
||||
zzupdate —— 升级 Ubuntu 的简单命令
|
||||
zzupdate：单条命令升级 Ubuntu 18.04 LTS
|
||||
======
|
||||
|
||||
Ubuntu 18.04 版本已经发布，并得到各个社区的一致好评，因为 Ubuntu 18.04 可能是 Ubuntu 多年来最令人兴奋的版本。
|
||||
|
||||
通常情况下，Ubuntu 及其衍生版可以使用命令从一个版本升级到最新版本或者其它版本，这也是官方推荐的升级方式。
|
||||
@ -16,20 +17,21 @@ Ubuntu 18.04 版本已经发布，并得到各个社区的一致好评，因为
|
||||
- 笔记本电脑在使用电池供电时会在无操作 20 分钟后自动待机
|
||||
- 不再提供 32 位的 Ubuntu 桌面安装程序映像
|
||||
|
||||
注意：
|
||||
|
||||
**注意：**
|
||||
1. 不要忘记备份重要数据。如果升级出现问题，我们将重新安装并恢复数据。
|
||||
2. 安装所需时间取决于您的网络状况和安装的程序。
|
||||
|
||||
### zzupdate 是什么？
|
||||
|
||||
我们可以通过使用 [zzupdate][2] 工具中的单个命令将 Ubuntu PC/Server 从一个版本升级到另一个版本。它是一个免费的开源工具，使用它不需要任何脚本知识，因为它只需要配置文件即可运行。
|
||||
我们可以只通过一条命令使用 [zzupdate][2] 工具中将 Ubuntu PC/Server 从一个版本升级到另一个版本。它是一个自由开源工具，使用它不需要任何脚本知识，因为它只需要配置文件即可运行。
|
||||
|
||||
工具中提供两个默认 shell 文件。`setup.sh` 自动安装、更新代码，将脚本转换为一个简单的 zzupdate shell 命令。`zzupdate.sh` 将执行版本间的升级。
|
||||
|
||||
### 如何安装 zzipdate？
|
||||
### 如何安装 zzupdate？
|
||||
|
||||
要安装 `zzupdate`，只需执行以下命令：
|
||||
|
||||
要安装 zzupdate，只需执行以下命令。
|
||||
```
|
||||
$ curl -s https://raw.githubusercontent.com/TurboLabIt/zzupdate/master/setup.sh | sudo sh
|
||||
.
|
||||
@ -46,24 +48,24 @@ Already up-to-date.
|
||||
Setup completed!
|
||||
----------------
|
||||
See https://github.com/TurboLabIt/zzupdate for the quickstart guide.
|
||||
|
||||
```
|
||||
|
||||
将 Ubuntu 系统从一个版本升级到另一个版本，您不需要输入很多命令，也不需要重新启动，只需要运行下面的 zzupdate 命令并坐下喝杯咖啡就可以了。
|
||||
将 Ubuntu 系统从一个版本升级到另一个版本，您不需要输入很多命令，也不需要重新启动，只需要运行下面的 `zzupdate` 命令并坐下喝杯咖啡就可以了。
|
||||
|
||||
请注意，当您远程升级系统时，建议您使用以下的工具来帮助您在任何断开连接时重新连接会话。
|
||||
|
||||
**建议阅读：** [如何让一个进程/命令在 SSH 连接断开后继续运行][3]
|
||||
建议阅读： [如何让一个进程/命令在 SSH 连接断开后继续运行][3]
|
||||
|
||||
### 如何配置 zzupdate（可选）
|
||||
|
||||
默认情况下，zzupdate 可以直接使用，不需要配置任何东西。当然，如果您想要自己配置一些内容，可以的。复制提供的实例配置文件 `zzupdate.default.conf` 到 `zzupdate.conf` 并在 `zzupdate.conf` 中配置您的首选项。
|
||||
默认情况下，`zzupdate` 可以开箱即用，不需要配置任何东西。当然，如果您想要自己配置一些内容也是可以的。复制提供的示例配置文件 `zzupdate.default.conf` 到 `zzupdate.conf`，并在 `zzupdate.conf` 中配置您的首选项。
|
||||
|
||||
```
|
||||
$ sudo cp /usr/local/turbolab.it/zzupdate/zzupdate.default.conf /etc/turbolab.it/zzupdate.conf
|
||||
|
||||
```
|
||||
|
||||
打开文件，默认配置如下。
|
||||
|
||||
```
|
||||
$ sudo nano /etc/turbolab.it/zzupdate.conf
|
||||
|
||||
@ -73,19 +75,18 @@ VERSION_UPGRADE=1
|
||||
VERSION_UPGRADE_SILENT=0
|
||||
COMPOSER_UPGRADE=1
|
||||
SWITCH_PROMPT_TO_NORMAL=0
|
||||
|
||||
```
|
||||
|
||||
* **`REBOOT=1 :`**系统在更新完成后自动重启
|
||||
* **`REBOOT_TIMEOUT=15 :`**重启的默认超时值
|
||||
* **`VERSION_UPGRADE=1 :`**执行从一个版本到另一个版本的版本升级
|
||||
* **`VERSION_UPGRADE_SILENT=0 :`**禁用自动升级
|
||||
* **`COMPOSER_UPGRADE=1 :`**自动升级
|
||||
* **`SWITCH_PROMPT_TO_NORMAL=0 :`**如果值为 `0`，将寻找相同种类的版本升级。例如您正在运行 LTS 的版本，那么将寻找 LTS 的版本升级，而不是用于正常版本升级。如果值为 `1`，那么无论您是运行 LTS 还是正常版本，都会查找最新版本
|
||||
* `REBOOT=1`：系统在更新完成后自动重启
|
||||
* `REBOOT_TIMEOUT=15`：重启的默认超时值
|
||||
* `VERSION_UPGRADE=1`：执行从一个版本到另一个版本的版本升级
|
||||
* `VERSION_UPGRADE_SILENT=0`：禁用自动升级
|
||||
* `COMPOSER_UPGRADE=1`：自动升级
|
||||
* `SWITCH_PROMPT_TO_NORMAL=0`：如果值为 `0`，将寻找相同种类的版本升级。例如您正在运行 LTS 的版本，那么将寻找 LTS 的版本升级，而不是用于正常版本升级。如果值为 `1`，那么无论您是运行 LTS 还是正常版本，都会查找最新版本
|
||||
|
||||
|
||||
我现在正在使用 Ubuntu 17.10 ，查看一下详细信息。
|
||||
|
||||
我现在使用 Ubuntu 17.10 并查看详细信息。
|
||||
```
|
||||
$ cat /etc/*-release
|
||||
DISTRIB_ID=Ubuntu
|
||||
@ -107,7 +108,8 @@ UBUNTU_CODENAME=artful
|
||||
|
||||
```
|
||||
|
||||
要升级 Ubuntu 到最新版本，只需要执行以下命令。
|
||||
要升级 Ubuntu 到最新版本，只需要执行以下命令：
|
||||
|
||||
```
|
||||
$ sudo zzupdate
|
||||
|
||||
@ -181,10 +183,10 @@ Fetched 0 B in 6s (0 B/s)
|
||||
Reading package lists... Done
|
||||
Building dependency tree
|
||||
Reading state information... Done
|
||||
|
||||
```
|
||||
|
||||
我们需要按下 `Enter` 按钮禁用 `Third Party` 仓库以继续升级。
|
||||
我们需要按下回车键禁用第三方仓库以继续升级。
|
||||
|
||||
```
|
||||
Updating repository information
|
||||
|
||||
@ -209,10 +211,10 @@ Reading state information... Done
|
||||
Calculating the changes
|
||||
|
||||
Calculating the changes
|
||||
|
||||
```
|
||||
|
||||
开始下载 `Ubuntu 18.04 LTS` 软件包，所需时间取决于您的网络状况，一般情况下这将需要几分钟。
|
||||
|
||||
```
|
||||
Do you want to start the upgrade?
|
||||
|
||||
@ -244,10 +246,10 @@ Get:1480 http://in.archive.ubuntu.com/ubuntu bionic/main amd64 usb-modeswitch am
|
||||
Get:1481 http://in.archive.ubuntu.com/ubuntu bionic/main amd64 usb-modeswitch-data all 20170806-2 [30.7 kB]
|
||||
Get:1482 http://in.archive.ubuntu.com/ubuntu bionic/main amd64 xbrlapi amd64 5.5-4ubuntu2 [61.8 kB]
|
||||
Fetched 999 MB in 6s (721 kB/s)
|
||||
|
||||
```
|
||||
|
||||
安装新软件包时，很少有服务需要重新启动。 点击 `Yes` 按钮，它会自动重启所需的服务。
|
||||
|
||||
```
|
||||
Upgrading
|
||||
Inhibiting until Ctrl+C is pressed...
|
||||
@ -280,6 +282,7 @@ Progress: [ 95%]
|
||||
```
|
||||
|
||||
现在删除旧版的、系统不再需要的包。点击 `y` 以删除。
|
||||
|
||||
```
|
||||
Searching for obsolete software
|
||||
ing package lists... 97%
|
||||
@ -312,7 +315,8 @@ Fetched 0 B in 0s (0 B/s)
|
||||
|
||||
```
|
||||
|
||||
升级成功，需要重启系统。点击 `Y` 以重启系统。
|
||||
升级成功，需要重启系统。点击 `y` 以重启系统。
|
||||
|
||||
```
|
||||
System upgrade is complete.
|
||||
|
||||
@ -325,9 +329,10 @@ Continue [yN]y
|
||||
|
||||
```
|
||||
|
||||
**注意：** 少数情况下，会要求您确认配置文件替换以继续安装。
|
||||
注意： 少数情况下，会要求您确认配置文件替换以继续安装。
|
||||
|
||||
查看升级后的系统详情：
|
||||
|
||||
查看升级后的系统详情。
|
||||
```
|
||||
$ cat /etc/*-release
|
||||
DISTRIB_ID=Ubuntu
|
||||
@ -346,7 +351,6 @@ BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
|
||||
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
|
||||
VERSION_CODENAME=bionic
|
||||
UBUNTU_CODENAME=bionic
|
||||
|
||||
```
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
@ -356,7 +360,7 @@ via: https://www.2daygeek.com/zzupdate-single-command-to-upgrade-ubuntu-18-04/
|
||||
作者：[PRAKASH SUBRAMANIAN][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[XiatianSummer](https://github.com/XiatianSummer)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,7 +1,11 @@
|
||||
如何在 Linux 中找到你的 IP 地址
|
||||
======
|
||||
|
||||
> 每个网站都有一个独有的公开 IP 地址，可供任何人从任何地方访问。
|
||||
|
||||
|
||||
互联网协议（IP）不需要介绍 - 我们每天都在使用它。即使你不直接使用它，当你在浏览器上输入 website-name.com 时，它会查找该 URL 的 IP 地址，然后加载该网站。
|
||||
|
||||
<ruby>互联网协议<rt>Internet Protocol</rt></ruby>（IP）不需要介绍 —— 我们每天都在使用它。即使你不直接使用它，当你在浏览器上输入 website-name.com 时，它会查找该 URL 的 IP 地址，然后加载该网站。
|
||||
|
||||
我们将 IP 地址分为两类：私有和公共。私有 IP 地址是你的无线路由（和公司内网）提供的私有 IP 地址。它们的范围是 10.xxx、172.16.xx-172.31.xx 和 192.168.xx，其中 x=0 到 255。公有 IP 地址，顾名思义，是“公共”的，你可以在世界上任何地方访问它。每个网站都有一个唯一的 IP 地址，任何人可在任何地点访问，这可被视为公共 IP 地址。
|
||||
|
||||
@ -9,7 +13,7 @@
|
||||
|
||||
IPv4 地址格式为 x.x.x.x，其中 x=0 到 255。有 2^32（大约 40 亿个）可能的 IPv4 地址。
|
||||
|
||||
IPv6 地址使用更复杂的十六进制。总的比特数是 128，这意味着有 2^128-340 后面有 36 个零！ - 可能的 IPv6 地址。IPv6 已经被引入解决了可预见的 IPv4 地址耗尽问题。
|
||||
IPv6 地址使用更复杂的十六进制。总的比特数是 128，这意味着有 2^128 （340 后面有 36 个零！）个可能的 IPv6 地址。IPv6 已经被引入解决了可预见的 IPv4 地址耗尽问题。
|
||||
|
||||
作为网络工程师，我建议不要与任何人共享你机器的公有 IP 地址。你的 WiFi 路由器有公共 IP，即 WAN（广域网）IP 地址，并且连接到该 WiFi 的任何设备都是相同的。连接到相同 WiFi 的所有设备都有上面所说的私有 IP 地址。例如，我的笔记本电脑的 IP 地址 192.168.0.5，而我的电话是 192.168.0.8。这些是私有 IP 地址，但两者都有相同的公有 IP 地址。
|
||||
|
||||
@ -26,8 +30,6 @@ IPv6 地址使用更复杂的十六进制。总的比特数是 128，这意味
|
||||
9. `curl bot.whatismyipaddress.com`
|
||||
10. `curl ipecho.net/plain`
|
||||
|
||||
|
||||
|
||||
以下命令将为你提供接口的私有 IP 地址：
|
||||
|
||||
1. `ifconfig -a`
|
||||
@ -37,8 +39,6 @@ IPv6 地址使用更复杂的十六进制。总的比特数是 128，这意味
|
||||
5. `(Fedora) Wifi-Settings→ click the setting icon next to the Wifi name that you are connected to → Ipv4 and Ipv6 both can be seen`
|
||||
6. `nmcli -p device show`
|
||||
|
||||
|
||||
|
||||
_注意：一些工具需要根据你正在使用的 Linux 发行版安装在你的系统上。另外，一些提到的命令使用第三方网站来获取 IP_
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
@ -48,7 +48,7 @@ via: https://opensource.com/article/18/5/how-find-ip-address-linux
|
||||
作者：[Archit Modi][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,140 +0,0 @@
|
||||
translating by cizezsy
|
||||
|
||||
How To Kill The Largest Process In An Unresponsive Linux System
|
||||
======
|
||||
|
||||
|
||||
I, as a blog writer, have bookmarked many blogs, websites and forums to refer Linux and Unix related notes. Sometimes, I had a lot of open tabs in my browser, so my system goes unresponsive for several minutes. I couldn't move the mouse cursor, or kill a process or close any opened tabs. At that times, I had no choice but to forcibly reset the system. Of course, I use **OneTab** and The **Great Suspender** extensions, but they didn 't help much either. I often ran out of memory. This is where **Early OOM** comes in help. For those wondering, it will kill the largest process in an unresponsive system when it has absolutely no other choices. Early OOM checks the amount of available memory and free swap 10 times a second. If both are below 10%, it will kill the largest process.
|
||||
|
||||
### Why Early OOM? Why not built-in OOM killer?
|
||||
|
||||
Before going into further, let me you give a short explanation of OOM killer, also known as **O** ut **O** f **M** emory killer. OOM killer is a process that the Kernel uses when the system is critically low on memory. The main task of OOM killer is to continue killing processes until enough memory is freed for the smooth functioning of the rest of the process that the Kernel is attempting to run. OOM killer will choose the best processes that are least important to the system and free up maximum memory and kill them. We can view the oom_score of each process in **/proc** directory under **pid** section.
|
||||
|
||||
Example:
|
||||
```
|
||||
$ cat /proc/10299/oom_score
|
||||
1
|
||||
```
|
||||
|
||||
The higher the value of oom_score of any process, the higher is its likelihood of getting killed by the OOM Killer when the system is running out of memory.
|
||||
|
||||
The developer of Early OOM claims that it has one big advantage over the in-kernel OOM killer. As I stated earlier, the Linux oom killer kills the process with the highest score, so the Chrome browser will always be the first victim of the oom killer. To avoid this, Early OOM uses **/proc/*/status** instead of **echo f > /proc/sysrq-trigger**. He also claims that triggering the oom killer manually may not work at all in latest Linux Kernel.
|
||||
|
||||
### Installing Early OOM
|
||||
|
||||
Early OOM is available in AUR, so you can install it using any AUR helper programs in Arch Linux and its derivatives.
|
||||
|
||||
Using [**Pacaur**][1]:
|
||||
```
|
||||
pacaur -S earlyoom
|
||||
```
|
||||
|
||||
Using [**Packer**][2]:
|
||||
```
|
||||
packer -S earlyoom
|
||||
```
|
||||
|
||||
Using [**Yaourt**][3]:
|
||||
```
|
||||
yaourt -S earlyoom
|
||||
```
|
||||
|
||||
Enable and start Early OOM daemon:
|
||||
```
|
||||
sudo systemctl enable earlyoom
|
||||
```
|
||||
```
|
||||
sudo systemctl start earlyoom
|
||||
```
|
||||
|
||||
On other Linux distributions, compile and install it manually as shown below.
|
||||
```
|
||||
git clone https://github.com/rfjakob/earlyoom.git
|
||||
cd earlyoom
|
||||
make
|
||||
sudo make install
|
||||
```
|
||||
|
||||
### Early OOM - Kill The Largest Process In An Unresponsive Linux System
|
||||
|
||||
Run the following command to start Early OOM:
|
||||
```
|
||||
earlyoom
|
||||
```
|
||||
|
||||
If you compiled it from source, run the following command to start Early OOM:
|
||||
```
|
||||
./earlyoom
|
||||
```
|
||||
|
||||
The sample output would be:
|
||||
```
|
||||
earlyoom 0.12
|
||||
mem total: 3863 MiB, min: 386 MiB (10 %)
|
||||
swap total: 2047 MiB, min: 204 MiB (10 %)
|
||||
mem avail: 1770 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1773 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1772 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1773 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1772 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1773 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1771 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1773 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1784 MiB (46 %), swap free: 2047 MiB (99 %)
|
||||
[...]
|
||||
```
|
||||
|
||||
As you see in the above output, Early OOM will display how much memory and swap you have, what the minimum is, how much memory is available and how much swap is free. Remember it will keep running until you manually stop by pressing CTRL+C.
|
||||
|
||||
If both memory and swap reaches below 10%, Early OOM will automatically kill the largest processes until the system has enough memory to run smoothly. You can also configure the minimum percentage value as per your requirement.
|
||||
|
||||
To set available memory minimum to PERCENT of total, run:``
|
||||
```
|
||||
earlyoom -m <PERCENT_HERE>
|
||||
```
|
||||
|
||||
To set available swap minimum to PERCENT of total, run:``
|
||||
```
|
||||
earlyoom -s <PERCENT_HERE>
|
||||
```
|
||||
|
||||
For more details, refer the help section.
|
||||
```
|
||||
$ earlyoom -h
|
||||
earlyoom 0.12
|
||||
Usage: earlyoom [OPTION]...
|
||||
|
||||
-m PERCENT set available memory minimum to PERCENT of total (default 10 %)
|
||||
-s PERCENT set free swap minimum to PERCENT of total (default 10 %)
|
||||
-M SIZE set available memory minimum to SIZE KiB
|
||||
-S SIZE set free swap minimum to SIZE KiB
|
||||
-k use kernel oom killer instead of own user-space implementation
|
||||
-i user-space oom killer should ignore positive oom_score_adj values
|
||||
-d enable debugging messages
|
||||
-v print version information and exit
|
||||
-r INTERVAL memory report interval in seconds (default 1), set to 0 to
|
||||
disable completely
|
||||
-p set niceness of earlyoom to -20 and oom_score_adj to -1000
|
||||
-h this help text
|
||||
```
|
||||
|
||||
Now, you don't need to worry about highest memory consumption processes. Hope this helps. More good stuffs to come. Stay tuned!
|
||||
|
||||
Cheers!
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/kill-largest-process-unresponsive-linux-system/
|
||||
|
||||
作者：[Aditya Goturu][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.ostechnix.com
|
||||
[1]:https://www.ostechnix.com/install-pacaur-arch-linux/
|
||||
[2]:https://www.ostechnix.com/install-packer-arch-linux-2/
|
||||
[3]:https://www.ostechnix.com/install-yaourt-arch-linux/
|
||||
@ -1,156 +0,0 @@
|
||||
Translating by qhwdw
|
||||
An introduction to Python bytecode
|
||||
======
|
||||
|
||||
If you've ever written, or even just used, Python, you're probably used to seeing Python source code files; they have names ending in `.py`. And you may also have seen another type of file, with a name ending in `.pyc`, and you may have heard that they're Python "bytecode" files. (These are a bit harder to see on Python 3—instead of ending up in the same directory as your `.py` files, they go into a subdirectory called `__pycache__`.) And maybe you've heard that this is some kind of time-saver that prevents Python from having to re-parse your source code every time it runs.
|
||||
|
||||
But beyond "oh, that's Python bytecode," do you really know what's in those files and how Python uses them?
|
||||
|
||||
If not, today's your lucky day! I'll take you through what Python bytecode is, how Python uses it to execute your code, and how knowing about it can help you.
|
||||
|
||||
### How Python works
|
||||
|
||||
Python is often described as an interpreted language—one in which your source code is translated into native CPU instructions as the program runs—but this is only partially correct. Python, like many interpreted languages, actually compiles source code to a set of instructions for a virtual machine, and the Python interpreter is an implementation of that virtual machine. This intermediate format is called "bytecode."
|
||||
|
||||
So those `.pyc` files Python leaves lying around aren't just some "faster" or "optimized" version of your source code; they're the bytecode instructions that will be executed by Python's virtual machine as your program runs.
|
||||
|
||||
Let's look at an example. Here's a classic "Hello, World!" written in Python:
|
||||
```
|
||||
def hello()
|
||||
|
||||
print("Hello, World!")
|
||||
|
||||
```
|
||||
|
||||
And here's the bytecode it turns into (translated into a human-readable form):
|
||||
```
|
||||
2 0 LOAD_GLOBAL 0 (print)
|
||||
|
||||
2 LOAD_CONST 1 ('Hello, World!')
|
||||
|
||||
4 CALL_FUNCTION 1
|
||||
|
||||
```
|
||||
|
||||
If you type up that `hello()` function and use the [CPython][1] interpreter to run it, the above listing is what Python will execute. It might look a little weird, though, so let's take a deeper look at what's going on.
|
||||
|
||||
### Inside the Python virtual machine
|
||||
|
||||
CPython uses a stack-based virtual machine. That is, it's oriented entirely around stack data structures (where you can "push" an item onto the "top" of the structure, or "pop" an item off the "top").
|
||||
|
||||
CPython uses three types of stacks:
|
||||
|
||||
1. The **call stack**. This is the main structure of a running Python program. It has one item—a "frame"—for each currently active function call, with the bottom of the stack being the entry point of the program. Every function call pushes a new frame onto the call stack, and every time a function call returns, its frame is popped off.
|
||||
2. In each frame, there's an **evaluation stack** (also called the **data stack** ). This stack is where execution of a Python function occurs, and executing Python code consists mostly of pushing things onto this stack, manipulating them, and popping them back off.
|
||||
3. Also in each frame, there's a **block stack**. This is used by Python to keep track of certain types of control structures: loops, `try`/`except` blocks, and `with` blocks all cause entries to be pushed onto the block stack, and the block stack gets popped whenever you exit one of those structures. This helps Python know which blocks are active at any given moment so that, for example, a `continue` or `break` statement can affect the correct block.
|
||||
|
||||
|
||||
|
||||
Most of Python's bytecode instructions manipulate the evaluation stack of the current call-stack frame, although there are some instructions that do other things (like jump to specific instructions or manipulate the block stack).
|
||||
|
||||
To get a feel for this, suppose we have some code that calls a function, like this: `my_function(my_variable, 2)`. Python will translate this into a sequence of four bytecode instructions:
|
||||
|
||||
1. A `LOAD_NAME` instruction that looks up the function object `my_function` and pushes it onto the top of the evaluation stack
|
||||
2. Another `LOAD_NAME` instruction to look up the variable `my_variable` and push it on top of the evaluation stack
|
||||
3. A `LOAD_CONST` instruction to push the literal integer value `2` on top of the evaluation stack
|
||||
4. A `CALL_FUNCTION` instruction
|
||||
|
||||
|
||||
|
||||
The `CALL_FUNCTION` instruction will have an argument of 2, which indicates that Python needs to pop two positional arguments off the top of the stack; then the function to call will be on top, and it can be popped as well (for functions involving keyword arguments, a different instruction—`CALL_FUNCTION_KW`—is used, but with a similar principle of operation, and a third instruction, `CALL_FUNCTION_EX`, is used for function calls that involve argument unpacking with the `*` or `**` operators). Once Python has all that, it will allocate a new frame on the call stack, populate the local variables for the function call, and execute the bytecode of `my_function` inside that frame. Once that's done, the frame will be popped off the call stack, and in the original frame the return value of `my_function` will be pushed on top of the evaluation stack.
|
||||
|
||||
### Accessing and understanding Python bytecode
|
||||
|
||||
If you want to play around with this, the `dis` module in the Python standard library is a huge help; the `dis` module provides a "disassembler" for Python bytecode, making it easy to get a human-readable version and look up the various bytecode instructions. [The documentation for the `dis` module][2] goes over its contents and provides a full list of bytecode instructions along with what they do and what arguments they take.
|
||||
|
||||
For example, to get the bytecode listing for the `hello()` function above, I typed it into a Python interpreter, then ran:
|
||||
```
|
||||
import dis
|
||||
|
||||
dis.dis(hello)
|
||||
|
||||
```
|
||||
|
||||
The function `dis.dis()` will disassemble a function, method, class, module, compiled Python code object, or string literal containing source code and print a human-readable version. Another handy function in the `dis` module is `distb()`. You can pass it a Python traceback object or call it after an exception has been raised, and it will disassemble the topmost function on the call stack at the time of the exception, print its bytecode, and insert a pointer to the instruction that raised the exception.
|
||||
|
||||
It's also useful to look at the compiled code objects Python builds for every function since executing a function makes use of attributes of those code objects. Here's an example looking at the `hello()` function:
|
||||
```
|
||||
>>> hello.__code__
|
||||
|
||||
<code object hello at 0x104e46930, file "<stdin>", line 1>
|
||||
|
||||
>>> hello.__code__.co_consts
|
||||
|
||||
(None, 'Hello, World!')
|
||||
|
||||
>>> hello.__code__.co_varnames
|
||||
|
||||
()
|
||||
|
||||
>>> hello.__code__.co_names
|
||||
|
||||
('print',)
|
||||
|
||||
```
|
||||
|
||||
The code object is accessible as the attribute `__code__` on the function and carries a few important attributes:
|
||||
|
||||
* `co_consts` is a tuple of any literals that occur in the function body
|
||||
* `co_varnames` is a tuple containing the names of any local variables used in the function body
|
||||
* `co_names` is a tuple of any non-local names referenced in the function body
|
||||
|
||||
|
||||
|
||||
Many bytecode instructions—particularly those that load values to be pushed onto the stack or store values in variables and attributes—use indices in these tuples as their arguments.
|
||||
|
||||
So now we can understand the bytecode listing of the `hello()` function:
|
||||
|
||||
1. `LOAD_GLOBAL 0`: tells Python to look up the global object referenced by the name at index 0 of `co_names` (which is the `print` function) and push it onto the evaluation stack
|
||||
2. `LOAD_CONST 1`: takes the literal value at index 1 of `co_consts` and pushes it (the value at index 0 is the literal `None`, which is present in `co_consts` because Python function calls have an implicit return value of `None` if no explicit `return` statement is reached)
|
||||
3. `CALL_FUNCTION 1`: tells Python to call a function; it will need to pop one positional argument off the stack, then the new top-of-stack will be the function to call.
|
||||
|
||||
|
||||
|
||||
The "raw" bytecode—as non-human-readable bytes—is also available on the code object as the attribute `co_code`. You can use the list `dis.opname` to look up the names of bytecode instructions from their decimal byte values if you'd like to try to manually disassemble a function.
|
||||
|
||||
### Putting bytecode to use
|
||||
|
||||
Now that you've read this far, you might be thinking "OK, I guess that's cool, but what's the practical value of knowing this?" Setting aside curiosity for curiosity's sake, understanding Python bytecode is useful in a few ways.
|
||||
|
||||
First, understanding Python's execution model helps you reason about your code. People like to joke about C being a kind of "portable assembler," where you can make good guesses about what machine instructions a particular chunk of C source code will turn into. Understanding bytecode will give you the same ability with Python—if you can anticipate what bytecode your Python source code turns into, you can make better decisions about how to write and optimize it.
|
||||
|
||||
Second, understanding bytecode is a useful way to answer questions about Python. For example, I often see newer Python programmers wondering why certain constructs are faster than others (like why `{}` is faster than `dict()`). Knowing how to access and read Python bytecode lets you work out the answers (try it: `dis.dis("{}")` versus `dis.dis("dict()")`).
|
||||
|
||||
Finally, understanding bytecode and how Python executes it gives a useful perspective on a particular kind of programming that Python programmers don't often engage in: stack-oriented programming. If you've ever used a stack-oriented language like FORTH or Factor, this may be old news, but if you're not familiar with this approach, learning about Python bytecode and understanding how its stack-oriented programming model works is a neat way to broaden your programming knowledge.
|
||||
|
||||
### Further reading
|
||||
|
||||
If you'd like to learn more about Python bytecode, the Python virtual machine, and how they work, I recommend these resources:
|
||||
|
||||
* [Inside the Python Virtual Machine][3] by Obi Ike-Nwosu is a free online book that does a deep dive into the Python interpreter, explaining in detail how Python actually works.
|
||||
* [A Python Interpreter Written in Python][4] by Allison Kaptur is a tutorial for building a Python bytecode interpreter in—what else—Python itself, and it implements all the machinery to run Python bytecode.
|
||||
* Finally, the CPython interpreter is open source and you can [read through it on GitHub][1]. The implementation of the bytecode interpreter is in the file `Python/ceval.c`. [Here's that file for the Python 3.6.4 release][5]; the bytecode instructions are handled by the `switch` statement beginning on line 1266.
|
||||
|
||||
|
||||
|
||||
To learn more, attend James Bennett's talk, [A Bit about Bytes: Understanding Python Bytecode][6], at [PyCon Cleveland 2018][7].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/4/introduction-python-bytecode
|
||||
|
||||
作者：[James Bennett][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/ubernostrum
|
||||
[1]:https://github.com/python/cpython
|
||||
[2]:https://docs.python.org/3/library/dis.html
|
||||
[3]:https://leanpub.com/insidethepythonvirtualmachine
|
||||
[4]:http://www.aosabook.org/en/500L/a-python-interpreter-written-in-python.html
|
||||
[5]:https://github.com/python/cpython/blob/d48ecebad5ac78a1783e09b0d32c211d9754edf4/Python/ceval.c
|
||||
[6]:https://us.pycon.org/2018/schedule/presentation/127/
|
||||
[7]:https://us.pycon.org/2018/
|
||||
@ -1,107 +0,0 @@
|
||||
What You Need to Know About Cryptocurrency ‘Malware’ Found on Ubuntu’s Snap Store
|
||||
======
|
||||
Recently, it was discovered that a couple of apps in the Ubuntu Snaps store contained cryptocurrency mining software. Canonical swiftly removed the offending apps, but several questions are left unanswered.
|
||||
|
||||
### Discovery of Crypto Miner on Snap Store
|
||||
|
||||
![Crypto Miner Malware on Ubuntu Snap Store][1]
|
||||
|
||||
On May 11, a user named [tarwirdur][2] opened a new issue on the [snapcraft.io repository][3]. In the issue, he noted that a snap entitled 2048buntu created by Nicolas Tomb contained a cryptocurrency miner. He asked how he could “complain about the application” for security reasons. tarwirdur later posted to say that all the others snaps created by Nicolas Tomb also contained cryptocurrency miners.
|
||||
|
||||
It appears that the snaps used systemd to automatically launch the code at boot and run it in the background with the user none the wiser.
|
||||
|
||||
{For those unfamiliar with the terminology, a cryptocurrency miner is a piece of software that uses a computer’s main processor or graphics processor to “mine” digital currency. “Mining” usually involves solving a mathematical equation. In this case, if you were running the 2048buntu game, the game used additional processing power for cryptocurrency mining.}
|
||||
|
||||
The Snapcraft team responded by quickly removing all apps created by the offender. They also started an investigation.
|
||||
|
||||
### The Man Behind the Mask Speaks
|
||||
|
||||
On May 13, a Disqus user named Nicolas Tomb [posted a comment][4] on OMGUbuntu’s coverage of the news. In this comment, he stated that he added the cryptocurrency miner to monetize the snaps. He apologized for his actions and promised to send any funds that had been mined to the Ubuntu foundation.
|
||||
|
||||
We can’t say for sure if this comment was posted by the same Nicolas Tomb since the Disqus account was just recently created and only has one comment associated with it. For now, we’ll assume that it is.
|
||||
|
||||
### Canonical Makes a Statement
|
||||
|
||||
On May 15, Canonical issued a statement on the situation. Entitled [“Trust and security in the Snap Store”][5], the post starts out by restating the situation. They add that the snaps have been [reissued with the cryptocurrency mining code removed][6].
|
||||
|
||||
Canonical then attempts to examine the motives of Nicolas Tomb. They note that he told them he did it in an attempt to monetize the apps (as stated above) and stopped doing it when confronted. They also note that “mining cryptocurrency is not illegal or unethical by itself”. They are however unhappy about the fact that he did not disclose the cryptocurrency miner in the snap description.
|
||||
|
||||
From there Canonical moves to the subject of reviewing software. According to the post, the Snap Store uses a quality control system similar to iOS, Android, and Windows: “automated checkpoints that packages must go through before they are accepted, and manual reviews by a human when specific issues are flagged”.
|
||||
|
||||
However, Canonical says “it’s impossible for a large scale repository to only accept software after every individual file has been reviewed in detail”. Therefore, they need to trust the source, not the content. After all, that is what the current Ubuntu repo system is based on.
|
||||
|
||||
Canonical follows this up by talking about the future of snaps. They acknowledge that the current system is not perfect. They are continually working to improve it. They have “very interesting security features in the works that will improve the safety of the system and also the experience of people handling software deployments in servers and desktops”.
|
||||
|
||||
One of the features they are working on is the ability to see if a publisher is verified. Other improvements include: “upstreaming of all the AppArmor kernel patches” and other under-the-hood fixes.
|
||||
|
||||
### Thoughts on the ‘Snap store malware’
|
||||
|
||||
Based on all that I’ve read, I’ve got a few thoughts and questions of my own.
|
||||
|
||||
#### How Long Was This Running?
|
||||
|
||||
First of all, how long have these mining snaps been available on the Snap Store? Since they have all been removed, we don’t have that data. I was able to grab an image of the 2048buntu page from the Google cache, but it doesn’t show much of anything. Depending on how long it ran, how many systems it got installed on, and what cryptocurrency was being mined, we could either be talks about a little bit of money or a pile. A further question is: would Canonical have been able to catch this in the future?
|
||||
|
||||
#### Was it Really a Malware?
|
||||
|
||||
A lot of news sites are reporting this as a malware infection. I think I might have even seen this incident referred to as Linux’s first malware. I’m not sure that term is accurate. Dictionary.com defines [malware][7] as: “software intended to damage a computer, mobile device, computer system, or computer network, or to take partial control over its operation”.
|
||||
|
||||
The snaps in question did not damage or take control of the computers involved. it also did not infect other computers. It couldn’t have because all snaps are sandboxed. At the most, they leached processor power, that’s about it. So, I wouldn’t call it malware.
|
||||
|
||||
#### Nothing Like a Loophole
|
||||
|
||||
The one defense that Nicolas Tomb uses is that the Snap Store didn’t have any rules against cryptocurrency mining when he uploaded the snaps. {I can bet you that they are rectifying that problem right now.} They didn’t have that rule for the simple reason that no one had done it before. If Tomb was trying to do things correctly, he should have asked if this kind of behavior was allowed. The fact that he didn’t seems to point to the fact that he knew they would probably say no. At the very least, they would have told him to put it in the description.
|
||||
|
||||
![][8]
|
||||
|
||||
#### Something Looks Hinkey
|
||||
|
||||
As I said before, I got a screenshot of the 2048buntu page from Google cache. Just looking at it raises several red flags. First, there is almost no real description. This is all it says “Game like 2048. This game is clone popular game – 2048 with ubuntu colors.” Wow. {That’ll bring in the suckers.} When I read something as empty as that, I get nervous.
|
||||
|
||||
Another thing to notice is the size of it. Version 1.0 of the 2048buntu snap weighs almost 140 MB. Why would a game this simple need that much space? There are browser versions written in Javascript that probably use less than a quarter of that. There other snaps of 2048 games on the Snap Store and none of them has half the file size.
|
||||
|
||||
Then, you have the license. This is a clone of a popular game using Ubuntu colors. How can it be considered proprietary? I’m sure that legit devs in the audience would have uploaded it with a FOSS (Free and Open Source Software) license just because of the content.
|
||||
|
||||
These factors alone should have made this snap, in particular, stand out and call for a review.
|
||||
|
||||
#### Who is Nicolas Tomb?
|
||||
|
||||
After first reading about this, I decided to see what I could find out about the guy who started this mess. When I searched for Nicolas Tomb, I found nothing, zip, nada, zilch. All I found were a bunch of news articles about the cryptocurrency mining snaps and information about taking a trip to the tomb of St. Nicolas. There is no sign of Nicolas Tomb on Twitter or Github either. This seems like a name created just to upload these snaps.
|
||||
|
||||
This also leads to a point in the Canonical blog post about verifying publishers. The last time I looked, quite a few snaps were not published by the maintainers of the applications. This makes me nervous. I would be more willing to trust a snap of say Firefox if it was published by Mozilla, instead of Leonard Borsch. If it’s too much work for the application maintainer to also take care of the snap, there should be a way for the maintainer to put their stamp of approval on the snap for their program. Something like Firefox snap published by Fredrick Ham, approved by Mozilla Foundation. Just something to give the user more confidence in what they are downloading.
|
||||
|
||||
#### Snap Store Definitely has Room to Improve
|
||||
|
||||
It seems to me that one of the first features that the Snap Store team should have implemented was a way to report suspicious snaps. tarwirdur had to find the site’s Github page. The average user would not have thought of that. If the Snap Store can’t review every line of code, enabling the users to reports problems is the next best thing. Even rating system would not be a bad addition. I’m sure there would have been a couple people who would have given 2048buntu a low rating for using too many system resources.
|
||||
|
||||
#### Conclusion
|
||||
|
||||
From all the I have seen, I think that someone created a number of simple apps, embedded a cryptocurrency miner in each, and uploaded them to the Snap Store with the goal of raking in piles of money. Once they got caught, they claimed it was only to monetize the snaps. If that was true, they would have mentioned it in the snap description. Hidden crypto miners are nothing [new][9]. They are generally a method of computing power theft.
|
||||
|
||||
I wish that Canonical already have features in place to combat this problem and I hope they appear quickly.
|
||||
|
||||
What do you think of the Snap Store ‘malware episode’? What would you do to improve it? Let us know in the comments below.
|
||||
|
||||
If you found this article interesting, please take a minute to share it on social media.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/snapstore-cryptocurrency-saga/
|
||||
|
||||
作者：[John Paul][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://itsfoss.com/author/john/
|
||||
[1]:https://4bds6hergc-flywheel.netdna-ssl.com/wp-content/uploads/2018/05/ubuntu-snap-malware-800x450.jpeg
|
||||
[2]:https://github.com/tarwirdur
|
||||
[3]:https://github.com/canonical-websites/snapcraft.io/issues/651
|
||||
[4]:https://disqus.com/home/discussion/omgubuntu/malware_found_on_the_ubuntu_snap_store/#comment-3899153046
|
||||
[5]:https://blog.ubuntu.com/2018/05/15/trust-and-security-in-the-snap-store
|
||||
[6]:https://forum.snapcraft.io/t/action-against-snap-store-malware/5417/8
|
||||
[7]:http://www.dictionary.com/browse/malware?s=t
|
||||
[8]:https://4bds6hergc-flywheel.netdna-ssl.com/wp-content/uploads/2018/05/2048buntu.png
|
||||
[9]:https://krebsonsecurity.com/2018/03/who-and-what-is-coinhive/
|
||||
@ -0,0 +1,138 @@
|
||||
如何在无响应的 Linux 系统中杀掉最大的进程
|
||||
======
|
||||
|
||||
|
||||
作为一名博客作者，我收藏了很多博客、网站和论坛用来标记 Linux 和 Unix 相关的内容。有时候，我在浏览器中开启了非常多的标签页，导致操作系统会无响应好几分钟。我不能移动我的鼠标去杀掉一个进程或关闭任何开启的标签页。在这种情况下，我别无选择，只能强制重启系统。当然我也用了 **OneTab** （译者注：OneTab 是一个 Chrome 的 Extension, 可以将标签页转化成一个列表保存。）和 **Greate Suspender** （译者注：Great Suspender 是一个 Chrome 的 Extension， 可以自动冻结标签页）这样浏览器拓展，但它们在这里也起不到太大的作用。 我经常耗尽我的内存。而这就是 **Early OOM** 起作用的时候了。在情况严重，它会杀掉一个未响应系统中的最大的进程。Early OOM 每秒会检测可用内存和空余交换区 10 次，一旦两者都低于 10%，它就会把最大的进程杀死。
|
||||
|
||||
### 为什么用 Early OOM？为什么不用系统内置的 OOM killer？
|
||||
|
||||
在继续讨论下去之前，我想先简短的介绍下 OOM killer，也就是 **O** ut **O** f **M** emory killer。OOM killer 是一个由内核在可用内存非常低的时候使用的进程。它的主要任务是不断的杀死进程，直到释放出足够的内存，是内核正在运行的进程的其余部分能顺利运行。OOM killer 会找到系统中最不重要并且能释放出最多内存的进程，然后杀掉他们。在 **/proc** 目录下的 **pid** 目录中，我们可以看到每个进程的 oom_score。
|
||||
|
||||
示例：
|
||||
```
|
||||
$ cat /proc/10299/oom_score
|
||||
1
|
||||
```
|
||||
|
||||
一个进程的 oom_score 的值越高，这个进程越有可能在系统内存耗尽的时候被 OOM killer 杀死。
|
||||
|
||||
Early OOM 的开发者表示，相对于内置的 OOM killer，Early OOM 有一个很大的优点。就像我之前说的那样，OOM killer 会杀掉 oom_score 最高的进程，而这也导致 Chrome 浏览器总是会成为第一个被杀死的进程。为了避免这种情况发生，Early OOM 使用 **/proc/*/status** 而不是 **echo f > /proc/sysrq-trigger**（译者注：这条命令会调用 OOM killer 杀死进程）。开发者还表示，手动触发 OOM killer 在最新版本的 Linux 内核中很可能不会起作用。
|
||||
|
||||
### 安装 Early OOM
|
||||
|
||||
Early OOM 在AUR（Arch User Repository）中可以被找到，所以你可以在 Arch 和它的衍生版本中使用任何 AUR 工具安装它。
|
||||
|
||||
使用 [**Pacaur**][1]：
|
||||
```
|
||||
pacaur -S earlyoom
|
||||
```
|
||||
|
||||
使用 [**Packer**][2]：
|
||||
```
|
||||
packer -S earlyoom
|
||||
```
|
||||
|
||||
使用 [**Yaourt**][3]：
|
||||
```
|
||||
yaourt -S earlyoom
|
||||
```
|
||||
|
||||
启用并启动 Early OOM daemon：
|
||||
```
|
||||
sudo systemctl enable earlyoom
|
||||
```
|
||||
```
|
||||
sudo systemctl start earlyoom
|
||||
```
|
||||
|
||||
在其它的 Linux 发行版中，可以按如下方法编译安装它
|
||||
```
|
||||
git clone https://github.com/rfjakob/earlyoom.git
|
||||
cd earlyoom
|
||||
make
|
||||
sudo make install
|
||||
```
|
||||
|
||||
### Early OOM - Kill The Largest Process In An Unresponsive Linux System杀掉无响应 Linux 系统中的最大的进程
|
||||
|
||||
运行如下命令启动 Early OOM：
|
||||
```
|
||||
earlyoom
|
||||
```
|
||||
|
||||
如果是通过编译源代码安装的， 运行如下命令启动 Early OOM：
|
||||
```
|
||||
./earlyoom
|
||||
```
|
||||
|
||||
示例输出：
|
||||
```
|
||||
earlyoom 0.12
|
||||
mem total: 3863 MiB, min: 386 MiB (10 %)
|
||||
swap total: 2047 MiB, min: 204 MiB (10 %)
|
||||
mem avail: 1770 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1773 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1772 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1773 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1772 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1773 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1771 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1773 MiB (45 %), swap free: 2047 MiB (99 %)
|
||||
mem avail: 1784 MiB (46 %), swap free: 2047 MiB (99 %)
|
||||
[...]
|
||||
```
|
||||
|
||||
就像你在上面的输出中可以看到的，Early OOM 将会显示你有多少内存和交换区，以及有多少可用的内存和交换区。记住它会一直保持运行，直到你按下 CTRL+C。
|
||||
|
||||
如果可用的内存和交换区大小都低于 10%，Early OOM 将会自动杀死最大的进程，直到系统有足够的内存可以流畅的运行。你也可以根据你的需求配置最小百分比值。
|
||||
|
||||
设置最小的可用内存百分比，运行：
|
||||
```
|
||||
earlyoom -m <PERCENT_HERE>
|
||||
```
|
||||
|
||||
设置最小可用交换区百分比, 运行:
|
||||
```
|
||||
earlyoom -s <PERCENT_HERE>
|
||||
```
|
||||
|
||||
在帮助部分，可以看到更多详细信息：
|
||||
```
|
||||
$ earlyoom -h
|
||||
earlyoom 0.12
|
||||
Usage: earlyoom [OPTION]...
|
||||
|
||||
-m PERCENT set available memory minimum to PERCENT of total (default 10 %)
|
||||
-s PERCENT set free swap minimum to PERCENT of total (default 10 %)
|
||||
-M SIZE set available memory minimum to SIZE KiB
|
||||
-S SIZE set free swap minimum to SIZE KiB
|
||||
-k use kernel oom killer instead of own user-space implementation
|
||||
-i user-space oom killer should ignore positive oom_score_adj values
|
||||
-d enable debugging messages
|
||||
-v print version information and exit
|
||||
-r INTERVAL memory report interval in seconds (default 1), set to 0 to
|
||||
disable completely
|
||||
-p set niceness of earlyoom to -20 and oom_score_adj to -1000
|
||||
-h this help text
|
||||
```
|
||||
|
||||
现在，你再也不用担心内存消耗最高的进程了。希望这能给你帮助。更多的好内容将会到来，敬请期待。
|
||||
|
||||
谢谢！
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/kill-largest-process-unresponsive-linux-system/
|
||||
|
||||
作者：[Aditya Goturu][a]
|
||||
译者：[cizezsy](https://github.com/cizezsy)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.ostechnix.com
|
||||
[1]:https://www.ostechnix.com/install-pacaur-arch-linux/
|
||||
[2]:https://www.ostechnix.com/install-packer-arch-linux-2/
|
||||
[3]:https://www.ostechnix.com/install-yaourt-arch-linux/
|
||||
155
translated/tech/20180423 An introduction to Python bytecode.md
Normal file
155
translated/tech/20180423 An introduction to Python bytecode.md
Normal file
@ -0,0 +1,155 @@
|
||||
Python 字节码介绍
|
||||
======
|
||||
|
||||
如果你从没有写过 Python，或者甚至只是使用过 Python，你或许已经习惯于看 Python 源代码文件；它们的名字以 `.py` 结尾。你可能还看到过其它类型的文件，比如使用 `.pyc` 结尾的文件，或许你可能听说过，它们就是 Python 的 "字节码" 文件。（在 Python 3 上这些可能不容易看到 — 因为它们与你的 `.py` 文件不在同一个目录下，它们在一个叫 `__pycache__` 的子目录中）或者你也听说过，这是节省时间的一种方法，它可以避免每次运行 Python 时去重新解析源代码。
|
||||
|
||||
但是，除了 “噢，原来这就是 Python 字节码” 之外，你还知道这些文件能做什么吗？以及 Python 是如何使用它们的？
|
||||
|
||||
如果你不知道，那你走运了！今天我将带你了解 Python 的字节码是什么，Python 如何使用它去运行你的代码，以及知道它是如何帮助你的。
|
||||
|
||||
### Python 如何工作
|
||||
|
||||
Python 经常被介绍为它是一个解释型语言 — 其中一个原因是程序运行时，你的源代码被转换成 CPU 的原生指令 — 但这样认为只是部分正确。Python 与大多数解释型语言一样，确实是将源代码编译为一组虚拟机指令，并且 Python 解释器是针对相应的虚拟机实现的。这种中间格式被称为 “字节码”。
|
||||
|
||||
因此，这些 `.pyc` 文件是 Python 悄悄留下的，是为了让它们运行的 “更快”，或者是针对你的源代码的 “优化” 版本；它们是你的程序在 Python 虚拟机上运行的字节码指令。
|
||||
|
||||
我们来看一个示例。这里是用 Python 写的经典程序 "Hello, World!"：
|
||||
```
|
||||
def hello()
|
||||
|
||||
print("Hello, World!")
|
||||
|
||||
```
|
||||
|
||||
下面是转换后的字节码（转换为人类可读的格式）：
|
||||
```
|
||||
2 0 LOAD_GLOBAL 0 (print)
|
||||
|
||||
2 LOAD_CONST 1 ('Hello, World!')
|
||||
|
||||
4 CALL_FUNCTION 1
|
||||
|
||||
```
|
||||
|
||||
如果你输入那个 `hello()` 函数，然后使用 [CPython][1] 解释器去运行它，上面的 Python 程序将会运行。它看起来可能有点奇怪，因此，我们来深入了解一下它都做了些什么。
|
||||
|
||||
### Python 虚拟机内幕
|
||||
|
||||
CPython 使用一个基于栈的虚拟机。也就是说，它完全面向栈数据结构的（你可以 “推入” 一个东西到栈 “顶”，或者，从栈 “顶” 上 “弹出” 一个东西来）。
|
||||
|
||||
CPython 使用三种类型的栈：
|
||||
|
||||
1. **调用栈**。这是运行 Python 程序的主要结构。它为每个当前活动的函数调用使用了一个东西 — "帧“，栈底是程序的入口点。每个函数调用推送一个新帧到调用栈，每当函数调用返回后，这个帧被销毁。
|
||||
2. 在每个帧中，有一个 **计算栈** （也称为 **数据栈**）。这个栈就是 Python 函数运行的地方，运行的 Python 代码大多数是由推入到这个栈中的东西组成的，操作它们，然后在返回后销毁它们。
|
||||
3. 在每个帧中，还有一个 **块栈**。它被 Python 用于去跟踪某些类型的控制结构：loops、`try`/`except` 块、以及 `with` 块，全部推入到块栈中，当你退出这些控制结构时，块栈被销毁。这将帮助 Python 了解任意给定时刻哪个块是活动的，比如，一个 `continue` 或者 `break` 语句可能影响正确的块。
|
||||
|
||||
|
||||
|
||||
大多数 Python 字节码指令操作的是当前调用栈帧的计算栈，虽然，还有一些指令可以做其它的事情（比如跳转到指定指令，或者操作块栈）。
|
||||
|
||||
为了更好地理解，假设我们有一些调用函数的代码，比如这个：`my_function(my_variable, 2)`。Python 将转换为一系列字节码指令：
|
||||
|
||||
1. 一个 `LOAD_NAME` 指令去查找函数对象 `my_function`，然后将它推入到计算栈的顶部
|
||||
2. 另一个 `LOAD_NAME` 指令去查找变量 `my_variable`，然后将它推入到计算栈的顶部
|
||||
3. 一个 `LOAD_CONST` 指令去推入一个实整数值 `2` 到计算栈的顶部
|
||||
4. 一个 `CALL_FUNCTION` 指令
|
||||
|
||||
|
||||
|
||||
这个 `CALL_FUNCTION` 指令将有 2 个参数，它表示那个 Python 需要从栈顶弹出两个位置参数；然后函数将在它上面进行调用，并且它也同时被弹出（对于函数涉及的关键字参数，它使用另一个不同的指令 — `CALL_FUNCTION_KW`，但使用的操作原则类似，以及第三个指令 — `CALL_FUNCTION_EX`，它适用于函数调用涉及到使用 `*` 或 `**` 操作符的情况）。一旦 Python 拥有了这些之后，它将在调用栈上分配一个新帧，填充到函数调用的本地变量上，然后，运行那个帧内的 `my_function` 字节码。运行完成后，这个帧将被调用栈销毁，最初的帧内返回的 `my_function` 将被推入到计算栈的顶部。
|
||||
|
||||
### 访问和理解 Python 字节码
|
||||
|
||||
如果你想玩转字节码，那么，Python 标准库中的 `dis` 模块将对你有非常大的帮助；`dis` 模块为 Python 字节码提供了一个 "反汇编"，它可以让你更容易地得到一个人类可读的版本，以及查找各种字节码指令。[`dis` 模块的文档][2] 可以让你遍历它的内容，并且提供一个字节码指令能够做什么和有什么样的参数的完整清单。
|
||||
|
||||
例如，获取上面的 `hello()` 函数的列表，可以在一个 Python 解析器中输入如下内容，然后运行它：
|
||||
```
|
||||
import dis
|
||||
|
||||
dis.dis(hello)
|
||||
|
||||
```
|
||||
|
||||
函数 `dis.dis()` 将反汇编一个函数、方法、类、模块、编译过的 Python 代码对象、或者字符串包含的源代码，以及显示出一个人类可读的版本。`dis` 模块中另一个方便的功能是 `distb()`。你可以给它传递一个 Python 追溯对象，或者发生预期外情况时调用它，然后它将反汇编发生预期外情况时在调用栈上最顶端的函数，并显示它的字节码，以及插入一个指向到引发意外情况的指令的指针。
|
||||
|
||||
它也可以用于查看 Python 为每个函数构建的编译后的代码对象，因为运行一个函数将会用到这些代码对象的属性。这里有一个查看 `hello()` 函数的示例：
|
||||
```
|
||||
>>> hello.__code__
|
||||
|
||||
<code object hello at 0x104e46930, file "<stdin>", line 1>
|
||||
|
||||
>>> hello.__code__.co_consts
|
||||
|
||||
(None, 'Hello, World!')
|
||||
|
||||
>>> hello.__code__.co_varnames
|
||||
|
||||
()
|
||||
|
||||
>>> hello.__code__.co_names
|
||||
|
||||
('print',)
|
||||
|
||||
```
|
||||
|
||||
代码对象在函数中可以作为属性 `__code__` 来访问，并且携带了一些重要的属性：
|
||||
|
||||
* `co_consts` 是存在于函数体内的任意实数的元组
|
||||
* `co_varnames` 是函数体内使用的包含任意本地变量名字的元组
|
||||
* `co_names` 是在函数体内引用的任意非本地名字的元组
|
||||
|
||||
|
||||
|
||||
许多字节码指令 — 尤其是那些推入到栈中的加载值，或者在变量和属性中的存储值 — 在这些用作它们参数的元组中使用索引。
|
||||
|
||||
因此，现在我们能够理解 `hello()` 函数中所列出的字节码：
|
||||
|
||||
1. `LOAD_GLOBAL 0`：告诉 Python 通过 `co_names` （它是 `print` 函数）的索引 0 上的名字去查找它指向的全局对象，然后将它推入到计算栈
|
||||
2. `LOAD_CONST 1`：带入 `co_consts` 在索引 1 上的实数值，并将它推入（索引 0 上的实数值是 `None`，它表示在 `co_consts` 中，因为 Python 函数调用有一个隐式的返回值 `None`，如果没有显式的返回表达式，就返回这个隐式的值 ）。
|
||||
3. `CALL_FUNCTION 1`：告诉 Python 去调用一个函数；它需要从栈中弹出一个位置参数，然后，新的栈顶将被函数调用。
|
||||
|
||||
|
||||
|
||||
"原始的" 字节码 — 是非人类可读格式的字节 — 也可以在代码对象上作为 `co_code` 属性可用。如果你有兴趣尝试手工反汇编一个函数时，你可以从它们的十进制字节值中，使用列出 `dis.opname` 的方式去查看字节码指令的名字。
|
||||
|
||||
### 字节码的用处
|
||||
|
||||
现在，你已经了解的足够多了，你可能会想 ” OK，我认为它很酷，但是知道这些有什么实际价值呢？“由于对它很好奇，我们去了解它，但是除了好奇之外，Python 字节码在几个方面还是非常有用的。
|
||||
|
||||
首先，理解 Python 的运行模型可以帮你更好地理解你的代码。人们都开玩笑说，C 将成为一个 ”便携式汇编器“，在那里你可以很好地猜测出一段 C 代码转换成什么样的机器指令。理解 Python 字节码之后，你在使用 Python 时也具备同样的能力 — 如果你能预料到你的 Python 源代码将被转换成什么样的字节码，那么你可以知道如何更好地写和优化 Python 源代码。
|
||||
|
||||
第二，理解字节码可以帮你更好地回答有关 Python 的问题。比如，我经常看到一些 Python 新手困惑为什么某些结构比其它结构运行的更快（比如，为什么 `{}` 比 `dict()` 快）。知道如何去访问和阅读 Python 字节码将让你很容易回答这样的问题（尝试对比一下： `dis.dis("{}")` 与 `dis.dis("dict()")` 就会明白）。
|
||||
|
||||
最后，理解字节码和 Python 如何运行它，为 Python 程序员不经常使用的一种特定的编程方式提供了有用的视角：面向栈的编程。如果你以前从来没有使用过像 FORTH 或 Fator 这样的面向栈的编程语言，它们可能有些古老，但是，如果你不熟悉这种方法，学习有关 Python 字节码的知识，以及理解面向栈的编程模型是如何工作的，将有助你开拓你的编程视野。
|
||||
|
||||
### 延伸阅读
|
||||
|
||||
如果你想进一步了解有关 Python 字节码、Python 虚拟机、以及它们是如何工作的更多知识，我推荐如下的这些资源：
|
||||
|
||||
* [Python 虚拟机内幕][3]，它是 Obi Ike-Nwosu 写的一本免费在线电子书，它深入 Python 解析器，解释了 Python 如何工作的细节。
|
||||
* [一个用 Python 编写的 Python 解析器][4]，它是由 Allison Kaptur 写的一个教程，它是用 Python 构建的 Python 字节码解析器，并且它实现了运行 Python 字节码的全部构件。
|
||||
* 最后，CPython 解析器是一个开源软件，你可以在 [GitHub][1] 上阅读它。它在文件 `Python/ceval.c` 中实现了字节码解析器。[这是 Python 3.6.4 发行版中那个文件的链接][5]；字节码指令是由第 1266 行开始的 `switch` 语句来处理的。
|
||||
|
||||
|
||||
|
||||
学习更多内容，参与到 James Bennett 的演讲，[有关字节的知识：理解 Python 字节码][6]，将在 [PyCon Cleveland 2018][7] 召开。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/4/introduction-python-bytecode
|
||||
|
||||
作者：[James Bennett][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/ubernostrum
|
||||
[1]:https://github.com/python/cpython
|
||||
[2]:https://docs.python.org/3/library/dis.html
|
||||
[3]:https://leanpub.com/insidethepythonvirtualmachine
|
||||
[4]:http://www.aosabook.org/en/500L/a-python-interpreter-written-in-python.html
|
||||
[5]:https://github.com/python/cpython/blob/d48ecebad5ac78a1783e09b0d32c211d9754edf4/Python/ceval.c
|
||||
[6]:https://us.pycon.org/2018/schedule/presentation/127/
|
||||
[7]:https://us.pycon.org/2018/
|
||||
@ -0,0 +1,107 @@
|
||||
关于在 Ubuntu Snap 应用商店上发现的加密货币 ‘恶意软件’ 需要了解的内容
|
||||
======
|
||||
最近，有发现称一些 Ubuntu Snaps 应用商店上的应用包含加密货币挖矿程序。Canonical 公司迅速下架了这些违规的应用，但是留下了几个有待回答的问题。
|
||||
|
||||
### 在 Snap 应用商店上发现了加密矿工
|
||||
|
||||
![Crypto Miner Malware on Ubuntu Snap Store][1]
|
||||
|
||||
5月11号，一位名叫 [tarwirdur][2] 的用户在 [snapcraft.io repository][3] 开了一个新的 issue ，他提到一个由 Nicolas Tomb 开发，叫做 2048buntu 的 snap 应用包含加密货币矿工。tarwirdur 询问他怎样才能因为安全原因“抱怨应用” 。tarwirdur 后来发表说其他由 Nicolas Tomb 开发的 snap 应用都包含加密货币矿工。
|
||||
|
||||
看起来 snap 应用使用了 systemd 在系统启动时自动地运行代码，并在用户不知情的情况下在后台运行。
|
||||
|
||||
{对那些不熟悉相关术语的人来说，加密货币矿工是一段占用计算机主处理器或者图形处理器来“挖掘”数字货币的程序。“挖矿”通常涉及到解决一个数学等式。在这种情况下，如果你在运行 2048buntu 游戏，这个游戏将会使用处理器额外的计算能力去进行加密货币的挖掘。}
|
||||
|
||||
Snapcraft 团队迅速地下架了所有由违规者开发的应用来做出回应。他们同时也开展了调查。
|
||||
|
||||
### 隐匿者发声
|
||||
|
||||
5月13号，一位同名为 Nicolas Tomb 的 Disqus 用户在 OMGUbuntu 的新闻报道上发表了[评论][4]，他在评论中称自己向 snap 应用中添加了加密货币矿工，从而获取收益。他为他的行为道歉，同时承诺将所有挖矿所得的收益送给 Ubuntu 基金会。
|
||||
|
||||
我们不能确认这个评论就是由 Nicolas Tomb 发表的，因为这个 Disqus 账户最近才被创建，也只有一条评论与之相关联。现在，我们假设是的。
|
||||
|
||||
### Canonical 公司发表了声明
|
||||
|
||||
5月15号，Canonical 公司在这种情况下发表了一份声明。标题为 [“Trust and security in the Snap Store”][5]，声明开头重申了当下的情况。他们也补充道[重新发布的 snap 应用中加密货币挖矿程序已经被删除了][6]。
|
||||
|
||||
Canonical 公司随后尝试检测 Nicolas Tomb 的动机。他们指出到他称自己这样做是为了通过应用赚钱（如上所诉），而在真的面对赚钱时就停止了。他们也指出“挖掘加密货币本身是不合法也是不道德的”。然而，他们对实际情况仍旧是不满意的，因为 Nicolas Tomb 没有在 snap 应用的描述中透露加密货币矿工。
|
||||
|
||||
随后 Canonical 公司将主题转移到审核软件上。根据这份申明，Snap 应用商店将会采用一种类似 iOS，Android，Windows 的质量控制系统，这个系统将“自动化检查点，安装包必须在被接受前通过检查，同时在特殊问题被标记时会进行人工审核”。
|
||||
|
||||
然而，Canonical 公司声称“对巨大而弹性的软件仓库来说，只接受每个单独文件都被仔细审核的软件是不可能的”。因此，他们需要相信软件源而不是基于源开发的应用。毕竟，软件源是现在 Ubuntu 软件仓库系统的基础。
|
||||
|
||||
Canonical 公司紧接着谈到了 snap 应用的未来。他们承认现在的系统是不完美的。他们也在不断工作进行改善。他们“在目前的工作中有非常有趣的安全功能，这些功能将会改善系统安全性同时提升人们在服务器或桌面上进行软件开发的体验”。
|
||||
|
||||
其中一个他们正在开发的功能是查看一个软件发布者是否已通过验证。Other improvements include: “upstreaming of all the AppArmor kernel patches” and other under-the-hood fixes.(不确定，under-the-hood 指实现是不透明的，[quora回答](https://www.quora.com/What-does-under-the-hood-mean-in-programming) ，其他的改善包括：“所有 AppArmor 内核补丁的上游”和其他黑盒服务都被修复了。)
|
||||
|
||||
### 一些关于'Snap 应用商店恶意软件'的想法
|
||||
|
||||
基于我读过的所有内容，我产生了了一些想法和问题。
|
||||
|
||||
#### 这种挖矿软件运行多久了？
|
||||
|
||||
首先，这些挖矿软件存在于 Snap 应用商店多久了？因为它们已经被下架了，我们没有这样的数据。我可以通过 Google 快照抓取一些 2048buntu 页面的图片，但这没有提供任何可用的信息。根据软件运行时间，多少系统安装过，什么加密货币被挖掘出了，我们可以谈谈违规者获取的一点钱或一笔钱。一个更长远的问题是：Canonical 公司将来有能力捕捉到这样的违规情况吗？
|
||||
|
||||
#### 这真的是一个恶意软件吗？
|
||||
|
||||
许多新闻网站将之报道为恶意软件感染。我想我甚至可以看到这个事件被称为 Linux 的第一个恶意软件。我不确定这个术语是否精确。Dictionary.com 这样定义 [恶意软件][7]：“意图损害计算机、移动设备、计算机系统或者计算机网络，或者对其运作进行部分控制的软件”。
|
||||
|
||||
有问题的 snap 应用并没有损害或者控制涉及到的计算机。它同样没有感染其他计算机。它也不能这样做，因为所有的 snap 应用位于沙盒之中。它们最多利用了处理器的计算能力，就是这样。所以，我不会称之为恶意软件。
|
||||
|
||||
#### Nothing Like a Loophole(无孔不入？)
|
||||
|
||||
Nicolas Tomb 使用的一个辩解是在他上传应用的时候 Snap 应用商店没有任何反对加密货币挖矿的规则。{我敢向你打赌他们正在纠正这个错误。}他们之所以没有这样的规则，原因很简单，之前没有人做过这种事。如果 Tomb 想正确地做事，他应该提前询问是否允许这种行为。而事实是他似乎没有指出他知道 Canonical 公司可能会拒绝的事实。至少，Canonical 公司会告诉他将这些写在软件的描述中。
|
||||
|
||||
![][8]
|
||||
|
||||
#### Something Looks Hinkey(不会翻译)
|
||||
|
||||
如我之前说的，我从 Google 快照获取了一个 2048buntu 的页面截图。仅仅看它就会感觉到一些危险的信号。首先，截图中几乎没有真实的描述。它是这样描述的“类似2048的游戏。这个游戏用 ubuntu 主题克隆了流行的游戏 — 2048。”哇，{这将会引来容易上当受骗的人。}当我读到类似空洞的描述时，我会多考虑下。
|
||||
|
||||
我注意到的另一件事是软件的大小。2048buntu 的 1.0 版本大小将近 140 MB。一个简单的游戏怎么需要这么多的空间？有用 Javascript 写的浏览器版本大概只用了不到它的四分之一。其他 snap 应用商店的 2048 游戏的大小没有一个达到了这个软件的一半。
|
||||
|
||||
然后，你有许可证。这是一个使用了 Ubuntu 主题的流行游戏的克隆。它如何被认为是专有的？我确信，其他合法的开发者会因为内容而使用了 FOSS （自由开源软件）许可证来上传它。
|
||||
|
||||
单是这些因素就使得这个 snap 应用很特殊，并呼吁进行审核。
|
||||
|
||||
#### 谁是 Nicolas Tomb？
|
||||
|
||||
当第一次读到这些之后，我决定看看我能否找出造成这一团混乱的人。当我搜索 Nicolas Tomb 的时候，我什么都没找到，zip，nada，zilch(感觉是错误，不太明白这几个单词在这里的意思)。所有我找到的只是一大堆关于加密货币挖矿 snap 应用的新闻和文章，以及去 tomb of St. Nicolas 旅游的信息。在 Twiter 和 Github 上都没有 Nicolas Tomb 的标志。看起来似乎是为了上传这些 snap 应用才创建的名称。
|
||||
|
||||
这同样引出了 Canonical 公司发表的申明中的一点，关于验证发布者。上一次我查看的时候，相当多的 snap 应用不是由应用的维护者发布的。这让我感到担忧。我更乐意相信 firefox 的 snap 应用是由 Mozilla 基金会发布的，而不是 Leonard Borsch。如果对应用维护者来说关注应用的 snap 版本太耗费精力，应该有办法让维护者在他们软件的 snap 版本上贴上批准的标签。就像是 Firefox 的 snap 版本由 Fredrick 发布，经 Mozilla 基金会批准。只是为了让用户对下载的内容更放心。
|
||||
|
||||
#### Snap 应用商店无疑有改善的空间
|
||||
|
||||
在我看来，Snap 应用商店团队应该实现的第一个特性是报告可疑应用的方式。tarwirdur 必须找到该网站的 Github 页面。大多数用户不会想到这一点。如果 Snap 应用商店不能审核每一行代码，使用户能够报告问题是下一个最好的事情。即使评分系统也不会是一个坏的补充。我确信一定有部分人因为 2048buntu 使用了太多系统资源而给它很低的评分。
|
||||
|
||||
#### 结论
|
||||
|
||||
从我所见过的来说，我认为某个人开发了一些简单的应用，在每个应用中嵌入了加密货币矿工，之后将这些应用上传到 Snap 应用商店，想着捞一笔钱。一旦他们被抓了，他们就声称这仅仅为了通过应用程序获利。如果这是真的，他们应该已经在 snap 应用的描述中提到了。隐藏加密矿工并不是什么[新鲜事][9]。他们通常是一种盗取计算能力的方法。
|
||||
|
||||
我希望 Canonical 公司已经具备了解决这个问题的功能，盼望这些功能能很快出来。
|
||||
|
||||
你对 Snap 应用商店的‘恶意软件风波’有什么看法？你将如何改善这种情况？请在下面的评论中告诉我们。
|
||||
|
||||
如果你觉得这篇文章有趣，请花费一点时间将它分享到社交媒体上。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/snapstore-cryptocurrency-saga/
|
||||
|
||||
作者：[John Paul][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[paperzhang](https://github.com/paperzhang)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://itsfoss.com/author/john/
|
||||
[1]:https://4bds6hergc-flywheel.netdna-ssl.com/wp-content/uploads/2018/05/ubuntu-snap-malware-800x450.jpeg
|
||||
[2]:https://github.com/tarwirdur
|
||||
[3]:https://github.com/canonical-websites/snapcraft.io/issues/651
|
||||
[4]:https://disqus.com/home/discussion/omgubuntu/malware_found_on_the_ubuntu_snap_store/#comment-3899153046
|
||||
[5]:https://blog.ubuntu.com/2018/05/15/trust-and-security-in-the-snap-store
|
||||
[6]:https://forum.snapcraft.io/t/action-against-snap-store-malware/5417/8
|
||||
[7]:http://www.dictionary.com/browse/malware?s=t
|
||||
[8]:https://4bds6hergc-flywheel.netdna-ssl.com/wp-content/uploads/2018/05/2048buntu.png
|
||||
[9]:https://krebsonsecurity.com/2018/03/who-and-what-is-coinhive/
|
||||
Loading…
Reference in New Issue
Block a user