分类技术下的文章

在 Linux 上用 SELinux 或 AppArmor 实现强制访问控制（MAC）

Gabriel Cánepa 发布于 2016-08-26
另请参阅: 系统运维,权限, SELinux, AppArmor, 访问控制
评论

为了解决标准的“用户-组-其他/读-写-执行”权限以及访问控制列表的限制以及加强安全机制，美国国家安全局（NSA）设计出一个灵活的强制访问控制（ Mandatory Access Control ）（MAC）方法 SELinux（Security Enhanced Linux 的缩写），来限制标准的权限之外的种种权限，在仍然允许对这个控制模型后续修改的情况下，让进程尽可能以最小权限访问或在系统对象（如文件，文件夹，网络端口等）上执行其他操作。

SELinux 和 AppArmor 加固 Linux 安全

另一个流行并且被广泛使用的 MAC 是 AppArmor，相比于 SELinux 它提供更多的特性，包括一个学习模式，可以让系统“学习”一个特定应用的行为，以及通过配置文件设置限制实现安全的应用使用。

在 CentOS 7 中，SELinux 合并进了内核并且默认启用强制（ Enforcing ）模式（下一节会介绍这方面更多的内容），与之不同的是，openSUSE 和 Ubuntu 使用的是 AppArmor 。

在这篇文章中我们会解释 SELinux 和 AppArmor 的本质，以及如何在你选择的发行版上使用这两个工具之一并从中获益。

SELinux 介绍以及如何在 CentOS 7 中使用

Security Enhanced Linux 可以以两种不同模式运行：

强制（ Enforcing ）：这种情况下，SELinux 基于 SELinux 策略规则拒绝访问，策略规则是一套控制安全引擎的规则。
宽容（ Permissive ）：这种情况下，SELinux 不拒绝访问，但如果在强制模式下会被拒绝的操作会被记录下来。

SELinux 也能被禁用。尽管这不是它的一个操作模式，不过也是一种选择。但学习如何使用这个工具强过只是忽略它。时刻牢记这一点！

使用 getenforce 命令来显示 SELinux 的当前模式。如果你想要更改模式，使用 setenforce 0（设置为宽容模式）或 setenforce 1（强制模式）。

因为这些设置重启后就失效了，你需要编辑 /etc/selinux/config 配置文件并设置 SELINUX 变量为 enforcing、permissive 或 disabled ，保存设置让其重启后也有效：

如何启用和禁用 SELinux 模式

还有一点要注意，如果 getenforce 返回 Disabled，你得编辑 /etc/selinux/config 配置文件为你想要的操作模式并重启。否则你无法利用 setenforce 设置（或切换）操作模式。

setenforce 的典型用法之一包括在 SELinux 模式之间切换（从强制到宽容或相反）来定位一个应用是否行为不端或没有像预期一样工作。如果它在你将 SELinux 设置为宽容模式正常工作，你就可以确定你遇到的是 SELinux 权限问题。

有两种我们使用 SELinux 可能需要解决的典型案例：

改变一个守护进程监听的默认端口。
给一个虚拟主机设置 /var/www/html 以外的文档根路径值。

让我们用以下例子来看看这两种情况。

例 1：更改 sshd 守护进程的默认端口

大部分系统管理员为了加强服务器安全首先要做的事情之一就是更改 SSH 守护进程监听的端口，主要是为了阻止端口扫描和外部攻击。要达到这个目的，我们要更改 /etc/ssh/sshd_config 中的 Port 值为以下值（我们在这里使用端口 9999 为例）：

Port 9999

在尝试重启服务并检查它的状态之后，我们会看到它启动失败：

# systemctl restart sshd
# systemctl status sshd

检查 SSH 服务状态

如果我们看看 /var/log/audit/audit.log，就会看到 sshd 被 SELinux 阻止在端口 9999 上启动，因为它是 JBoss 管理服务的保留端口（SELinux 日志信息包含了词语“AVC”，所以应该很容易把它同其他信息区分开来）：

# cat /var/log/audit/audit.log | grep AVC | tail -1

检查 Linux 审计日志

在这种情况下大部分人可能会禁用 SELinux，但我们不这么做。我们会看到有个让 SELinux 和监听其他端口的 sshd 和谐共处的方法。首先确保你有 policycoreutils-python 这个包，执行：

# yum install policycoreutils-python

查看 SELinux 允许 sshd 监听的端口列表。在接下来的图片中我们还能看到端口 9999 是为其他服务保留的，所以我们暂时无法用它来运行其他服务：

# semanage port -l | grep ssh

当然我们可以给 SSH 选择其他端口，但如果我们确定我们不会使用这台机器跑任何 JBoss 相关的服务，我们就可以修改 SELinux 已存在的规则，转而给 SSH 分配那个端口：

# semanage port -m -t ssh_port_t -p tcp 9999

这之后，我们就可以用前一个 semanage 命令检查端口是否正确分配了，即使用 -lC 参数（list custom 的简称）：

# semanage port -lC
# semanage port -l | grep ssh

给 SSH 分配端口

我们现在可以重启 SSH 服务并通过端口 9999 连接了。注意这个更改重启之后依然有效。

例 2：给一个虚拟主机设置 /var/www/html 以外的文档根路径（ DocumentRoot ）

如果你需要用除 /var/www/html 以外目录作为文档根目录（ DocumentRoot ）设置一个 Apache 虚拟主机（也就是说，比如 /websrv/sites/gabriel/public_html）：

DocumentRoot “/websrv/sites/gabriel/public_html”

Apache 会拒绝提供内容，因为 index.html 已经被标记为了 default_t SELinux 类型，Apache 无法访问它：

# wget http://localhost/index.html
# ls -lZ /websrv/sites/gabriel/public_html/index.html

被标记为 default\_t SELinux 类型

和之前的例子一样，你可以用以下命令验证这是不是 SELinux 相关的问题：

# cat /var/log/audit/audit.log | grep AVC | tail -1

检查日志确定是不是 SELinux 的问题

要将 /websrv/sites/gabriel/public_html 整个目录内容标记为 httpd_sys_content_t，执行：

# semanage fcontext -a -t httpd_sys_content_t "/websrv/sites/gabriel/public_html(/.*)?"

上面这个命令会赋予 Apache 对那个目录以及其内容的读取权限。

最后，要应用这条策略（并让更改的标记立即生效），执行：

# restorecon -R -v /websrv/sites/gabriel/public_html

现在你应该可以访问这个目录了：

# wget http://localhost/index.html

访问 Apache 目录

要获取关于 SELinux 的更多信息，参阅 Fedora 22 中的 SELinux 用户及管理员指南。

AppArmor 介绍以及如何在 OpenSUSE 和 Ubuntu 上使用它

AppArmor 的操作是基于写在纯文本文件中的规则定义，该文件中含有允许权限和访问控制规则。安全配置文件用来限制应用程序如何与系统中的进程和文件进行交互。

系统初始就提供了一系列的配置文件，但其它的也可以由应用程序在安装的时候设置或由系统管理员手动设置。

像 SELinux 一样，AppArmor 以两种模式运行。在强制（ enforce ）模式下，应用被赋予它们运行所需要的最小权限，但在抱怨（ complain ）模式下 AppArmor 允许一个应用执行受限的操作并将操作造成的“抱怨”记录到日志里（/var/log/kern.log，/var/log/audit/audit.log，和其它放在 /var/log/apparmor 中的日志）。

日志中会显示配置文件在强制模式下运行时会产生错误的记录，它们中带有 audit 这个词。因此，你可以在 AppArmor 的强制（ enforce ）模式下运行之前，先在抱怨（ complain ）模式下尝试运行一个应用并调整它的行为。

可以用这个命令显示 AppArmor 的当前状态：

$ sudo apparmor_status

查看 AppArmor 的状态

上面的图片指明配置 /sbin/dhclient，/usr/sbin/，和 /usr/sbin/tcpdump 等处在强制（ enforce ）模式下（在 Ubuntu 下默认就是这样的）。

因为不是所有的应用都包含相关的 AppArmor 配置，apparmor-profiles 包给其它没有提供限制的包提供了配置。默认它们配置在抱怨（ complain ）模式下运行，以便系统管理员能够测试并选择一个所需要的配置。

我们将会利用 apparmor-profiles，因为写一份我们自己的配置已经超出了 LFCS 认证的范围了。但是，由于配置都是纯文本文件，你可以查看并学习它们，为以后创建自己的配置做准备。

AppArmor 配置保存在 /etc/apparmor.d 中。让我们来看看这个文件夹在安装 apparmor-profiles 之前和之后有什么不同：

$ ls /etc/apparmor.d

查看 AppArmor 文件夹内容

如果你再次执行 sudo apparmor_status，你会在抱怨（ complain ）模式看到更长的配置文件列表。你现在可以执行下列操作。

将当前在强制（ enforce ）模式下的配置文件切换到抱怨（ complain ）模式：

$ sudo aa-complain /path/to/file

以及相反的操作（抱怨 –> 强制）：

$ sudo aa-enforce /path/to/file

上面这些例子是允许使用通配符的。举个例子：

$ sudo aa-complain /etc/apparmor.d/*

会将 /etc/apparmor.d 中的所有配置文件设置为抱怨（ complain ）模式，反之

$ sudo aa-enforce /etc/apparmor.d/*

会将所有配置文件设置为强制（ enforce ）模式。

要完全禁用一个配置，在 /etc/apparmor.d/disabled 目录中创建一个符号链接：

$ sudo ln -s /etc/apparmor.d/profile.name /etc/apparmor.d/disable/

要获取关于 AppArmor 的更多信息，参阅官方的 AppArmor wiki 以及 Ubuntu 提供的文档。

总结

在这篇文章中我们学习了一些 SELinux 和 AppArmor 这两个著名的强制访问控制系统的基本知识。什么时候使用两者中的一个或是另一个？为了避免提高难度，你可能需要考虑专注于你选择的发行版自带的那一个。不管怎样，它们会帮助你限制进程和系统资源的访问，以提高你服务器的安全性。

关于本文你有任何的问题，评论，或建议，欢迎在下方发表。不要犹豫，让我们知道你是否有疑问或评论。

via: http://www.tecmint.com/mandatory-access-control-with-selinux-or-apparmor-linux/

作者：Gabriel Cánepa 译者：alim0x 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

Mock 在 Python 单元测试中的使用

NAFTULI TZVI KAY 发布于 2016-08-26
另请参阅: 软件开发,python, 单元测试, mock
评论

本文讲述的是 Python 中 Mock 的使用。

如何执行单元测试而不用考验你的耐心

很多时候，我们编写的软件会直接与那些被标记为“垃圾”的服务交互。用外行人的话说：服务对我们的应用程序很重要，但是我们想要的是交互，而不是那些不想要的副作用，这里的“不想要”是在自动化测试运行的语境中说的。例如：我们正在写一个社交 app，并且想要测试一下 "发布到 Facebook" 的新功能，但是不想每次运行测试集的时候真的发布到 Facebook。

Python 的 unittest 库包含了一个名为 unittest.mock 或者可以称之为依赖的子包，简称为 mock —— 其提供了极其强大和有用的方法，通过它们可以模拟（ mock ）并去除那些我们不希望的副作用。

注意：mock 最近被收录到了 Python 3.3 的标准库中；先前发布的版本必须通过 PyPI 下载 Mock 库。

恐惧系统调用

再举另一个例子，我们在接下来的部分都会用到它，这是就是系统调用。不难发现，这些系统调用都是主要的模拟对象：无论你是正在写一个可以弹出 CD 驱动器的脚本，还是一个用来删除 /tmp 下过期的缓存文件的 Web 服务，或者一个绑定到 TCP 端口的 socket 服务器，这些调用都是在你的单元测试上下文中不希望产生的副作用。

作为一个开发者，你需要更关心你的库是否成功地调用了一个可以弹出 CD 的系统函数（使用了正确的参数等等），而不是切身经历 CD 托盘每次在测试执行的时候都打开了。（或者更糟糕的是，弹出了很多次，在一个单元测试运行期间多个测试都引用了弹出代码！）

同样，保持单元测试的效率和性能意味着需要让如此多的“缓慢代码”远离自动测试，比如文件系统和网络访问。

对于第一个例子来说，我们要从原始形式换成使用 mock 重构一个标准 Python 测试用例。我们会演示如何使用 mock 写一个测试用例，使我们的测试更加智能、快速，并展示更多关于我们软件的工作原理。

一个简单的删除函数

我们都有过需要从文件系统中一遍又一遍的删除文件的时候，因此，让我们在 Python 中写一个可以使我们的脚本更加轻易完成此功能的函数。

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os

def rm(filename):
    os.remove(filename)

很明显，我们的 rm 方法此时无法提供比 os.remove 方法更多的相关功能，但我们可以在这里添加更多的功能，使我们的基础代码逐步改善。

让我们写一个传统的测试用例，即，没有使用 mock：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from mymodule import rm

import os.path
import tempfile
import unittest

class RmTestCase(unittest.TestCase):

    tmpfilepath = os.path.join(tempfile.gettempdir(), "tmp-testfile")

    def setUp(self):
        with open(self.tmpfilepath, "wb") as f:
            f.write("Delete me!")

    def test_rm(self):
        # remove the file
        rm(self.tmpfilepath)
        # test that it was actually removed
        self.assertFalse(os.path.isfile(self.tmpfilepath), "Failed to remove the file.")

我们的测试用例相当简单，但是在它每次运行的时候，它都会创建一个临时文件并且随后删除。此外，我们没有办法测试我们的 rm 方法是否正确地将我们的参数向下传递给 os.remove 调用。我们可以基于以上的测试认为它做到了，但还有很多需要改进的地方。

使用 Mock 重构

让我们使用 mock 重构我们的测试用例：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from mymodule import rm

import mock
import unittest

class RmTestCase(unittest.TestCase):

    @mock.patch('mymodule.os')
    def test_rm(self, mock_os):
        rm("any path")
        # test that rm called os.remove with the right parameters
        mock_os.remove.assert_called_with("any path")

使用这些重构，我们从根本上改变了测试用例的操作方式。现在，我们有一个可以用于验证其他功能的内部对象。

潜在陷阱

第一件需要注意的事情就是，我们使用了 mock.patch 方法装饰器，用于模拟位于 mymodule.os 的对象，并且将 mock 注入到我们的测试用例方法。那么只是模拟 os 本身，而不是 mymodule.os 下 os 的引用（LCTT 译注：注意 @mock.patch('mymodule.os') 便是模拟 mymodule.os 下的 os），会不会更有意义呢？

当然，当涉及到导入和管理模块，Python 的用法就像蛇一样灵活。在运行时，mymodule 模块有它自己的被导入到本模块局部作用域的 os。因此，如果我们模拟 os，我们是看不到 mock 在 mymodule 模块中的模仿作用的。

这句话需要深刻地记住：

模拟一个东西要看它用在何处，而不是来自哪里。

如果你需要为 myproject.app.MyElaborateClass 模拟 tempfile 模块，你可能需要将 mock 用于 myproject.app.tempfile，而其他模块保持自己的导入。

先将那个陷阱放一边，让我们继续模拟。

向 ‘rm’ 中加入验证

之前定义的 rm 方法相当的简单。在盲目地删除之前，我们倾向于验证一个路径是否存在，并验证其是否是一个文件。让我们重构 rm 使其变得更加智能：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
import os.path

def rm(filename):
    if os.path.isfile(filename):
        os.remove(filename)

很好。现在，让我们调整测试用例来保持测试的覆盖率。

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from mymodule import rm

import mock
import unittest

class RmTestCase(unittest.TestCase):

    @mock.patch('mymodule.os.path')
    @mock.patch('mymodule.os')
    def test_rm(self, mock_os, mock_path):
        # set up the mock
        mock_path.isfile.return_value = False

        rm("any path")

        # test that the remove call was NOT called.
        self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")

        # make the file 'exist'
        mock_path.isfile.return_value = True

        rm("any path")

        mock_os.remove.assert_called_with("any path")

我们的测试用例完全改变了。现在我们可以在没有任何副作用的情况下核实并验证方法的内部功能。

将文件删除作为服务

到目前为止，我们只是将 mock 应用在函数上，并没应用在需要传递参数的对象和实例的方法上。我们现在开始涵盖对象的方法。

首先，我们将 rm 方法重构成一个服务类。实际上将这样一个简单的函数转换成一个对象，在本质上这不是一个合理的需求，但它能够帮助我们了解 mock 的关键概念。让我们开始重构：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
import os.path

class RemovalService(object):
    """A service for removing objects from the filesystem."""

    def rm(filename):
        if os.path.isfile(filename):
            os.remove(filename)

你会注意到我们的测试用例没有太大变化：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from mymodule import RemovalService

import mock
import unittest

class RemovalServiceTestCase(unittest.TestCase):

    @mock.patch('mymodule.os.path')
    @mock.patch('mymodule.os')
    def test_rm(self, mock_os, mock_path):
        # instantiate our service
        reference = RemovalService()

        # set up the mock
        mock_path.isfile.return_value = False

        reference.rm("any path")

        # test that the remove call was NOT called.
        self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")

        # make the file 'exist'
        mock_path.isfile.return_value = True

        reference.rm("any path")

        mock_os.remove.assert_called_with("any path")

很好，我们知道 RemovalService 会如预期般的工作。接下来让我们创建另一个服务，将 RemovalService 声明为它的一个依赖：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
import os.path

class RemovalService(object):
    """A service for removing objects from the filesystem."""

    def rm(self, filename):
        if os.path.isfile(filename):
            os.remove(filename)


class UploadService(object):

    def __init__(self, removal_service):
        self.removal_service = removal_service

    def upload_complete(self, filename):
        self.removal_service.rm(filename)

因为我们的测试覆盖了 RemovalService，因此我们不会对我们测试用例中 UploadService 的内部函数 rm 进行验证。相反，我们将调用 UploadService 的 RemovalService.rm 方法来进行简单测试（当然没有其他副作用），我们通过之前的测试用例便能知道它可以正确地工作。

这里有两种方法来实现测试：

模拟 RemovalService.rm 方法本身。
在 UploadService 的构造函数中提供一个模拟实例。

因为这两种方法都是单元测试中非常重要的方法，所以我们将同时对这两种方法进行回顾。

方法 1：模拟实例的方法

mock 库有一个特殊的方法装饰器，可以模拟对象实例的方法和属性，即 @mock.patch.object decorator 装饰器：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from mymodule import RemovalService, UploadService

import mock
import unittest

class RemovalServiceTestCase(unittest.TestCase):

    @mock.patch('mymodule.os.path')
    @mock.patch('mymodule.os')
    def test_rm(self, mock_os, mock_path):
        # instantiate our service
        reference = RemovalService()

        # set up the mock
        mock_path.isfile.return_value = False

        reference.rm("any path")

        # test that the remove call was NOT called.
        self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")

        # make the file 'exist'
        mock_path.isfile.return_value = True

        reference.rm("any path")

        mock_os.remove.assert_called_with("any path")


class UploadServiceTestCase(unittest.TestCase):

    @mock.patch.object(RemovalService, 'rm')
    def test_upload_complete(self, mock_rm):
        # build our dependencies
        removal_service = RemovalService()
        reference = UploadService(removal_service)

        # call upload_complete, which should, in turn, call `rm`:
        reference.upload_complete("my uploaded file")

        # check that it called the rm method of any RemovalService
        mock_rm.assert_called_with("my uploaded file")

        # check that it called the rm method of _our_ removal_service
        removal_service.rm.assert_called_with("my uploaded file")

非常棒！我们验证了 UploadService 成功调用了我们实例的 rm 方法。你是否注意到一些有趣的地方？这种修补机制（patching mechanism）实际上替换了我们测试用例中的所有 RemovalService 实例的 rm 方法。这意味着我们可以检查实例本身。如果你想要了解更多，可以试着在你模拟的代码下断点，以对这种修补机制的原理获得更好的认识。

陷阱：装饰顺序

当我们在测试方法中使用多个装饰器，其顺序是很重要的，并且很容易混乱。基本上，当装饰器被映射到方法参数时，装饰器的工作顺序是反向的。思考这个例子：

    @mock.patch('mymodule.sys')
    @mock.patch('mymodule.os')
    @mock.patch('mymodule.os.path')
    def test_something(self, mock_os_path, mock_os, mock_sys):
        pass

注意到我们的参数和装饰器的顺序是反向匹配了吗？这部分是由 Python 的工作方式所导致的。这里是使用多个装饰器的情况下它们执行顺序的伪代码：

patch_sys(patch_os(patch_os_path(test_something)))

因为 sys 补丁位于最外层，所以它最晚执行，使得它成为实际测试方法参数的最后一个参数。请特别注意这一点，并且在运行你的测试用例时，使用调试器来保证正确的参数以正确的顺序注入。

方法 2：创建 Mock 实例

我们可以使用构造函数为 UploadService 提供一个 Mock 实例，而不是模拟特定的实例方法。我更推荐方法 1，因为它更加精确，但在多数情况，方法 2 或许更加有效和必要。让我们再次重构测试用例：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from mymodule import RemovalService, UploadService

import mock
import unittest

class RemovalServiceTestCase(unittest.TestCase):

    @mock.patch('mymodule.os.path')
    @mock.patch('mymodule.os')
    def test_rm(self, mock_os, mock_path):
        # instantiate our service
        reference = RemovalService()

        # set up the mock
        mock_path.isfile.return_value = False

        reference.rm("any path")

        # test that the remove call was NOT called.
        self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")

        # make the file 'exist'
        mock_path.isfile.return_value = True

        reference.rm("any path")

        mock_os.remove.assert_called_with("any path")


class UploadServiceTestCase(unittest.TestCase):

    def test_upload_complete(self, mock_rm):
        # build our dependencies
        mock_removal_service = mock.create_autospec(RemovalService)
        reference = UploadService(mock_removal_service)

        # call upload_complete, which should, in turn, call `rm`:
        reference.upload_complete("my uploaded file")

        # test that it called the rm method
        mock_removal_service.rm.assert_called_with("my uploaded file")

在这个例子中，我们甚至不需要修补任何功能，只需为 RemovalService 类创建一个 auto-spec，然后将实例注入到我们的 UploadService 以验证功能。

mock.create_autospec 方法为类提供了一个同等功能实例。实际上来说，这意味着在使用返回的实例进行交互的时候，如果使用了非法的方式将会引发异常。更具体地说，如果一个方法被调用时的参数数目不正确，将引发一个异常。这对于重构来说是非常重要。当一个库发生变化的时候，中断测试正是所期望的。如果不使用 auto-spec，尽管底层的实现已经被破坏，我们的测试仍然会通过。

陷阱：mock.Mock 和 mock.MagicMock 类

mock 库包含了两个重要的类 mock.Mock 和 mock.MagicMock，大多数内部函数都是建立在这两个类之上的。当在选择使用 mock.Mock 实例、mock.MagicMock 实例还是 auto-spec 的时候，通常倾向于选择使用 auto-spec，因为对于未来的变化，它更能保持测试的健全。这是因为 mock.Mock 和 mock.MagicMock 会无视底层的 API，接受所有的方法调用和属性赋值。比如下面这个用例：

class Target(object):
    def apply(value):
        return value

def method(target, value):
    return target.apply(value)

我们可以像下面这样使用 mock.Mock 实例进行测试：

class MethodTestCase(unittest.TestCase):

    def test_method(self):
        target = mock.Mock()

        method(target, "value")

        target.apply.assert_called_with("value")

这个逻辑看似合理，但如果我们修改 Target.apply 方法接受更多参数：

class Target(object):
    def apply(value, are_you_sure):
        if are_you_sure:
            return value
        else:
            return None

重新运行你的测试，你会发现它仍能通过。这是因为它不是针对你的 API 创建的。这就是为什么你总是应该使用 create_autospec 方法，并且在使用 @patch和 @patch.object 装饰方法时使用 autospec 参数。

现实例子：模拟 Facebook API 调用

作为这篇文章的结束，我们写一个更加适用的现实例子，一个在介绍中提及的功能：发布消息到 Facebook。我将写一个不错的包装类及其对应的测试用例。

import facebook

class SimpleFacebook(object):

    def __init__(self, oauth_token):
        self.graph = facebook.GraphAPI(oauth_token)

    def post_message(self, message):
        """Posts a message to the Facebook wall."""
        self.graph.put_object("me", "feed", message=message)

这是我们的测试用例，它可以检查我们发布的消息,而不是真正地发布消息：

import facebook
import simple_facebook
import mock
import unittest

class SimpleFacebookTestCase(unittest.TestCase):

    @mock.patch.object(facebook.GraphAPI, 'put_object', autospec=True)
    def test_post_message(self, mock_put_object):
        sf = simple_facebook.SimpleFacebook("fake oauth token")
        sf.post_message("Hello World!")

        # verify
        mock_put_object.assert_called_with(message="Hello World!")

正如我们所看到的，在 Python 中，通过 mock，我们可以非常容易地动手写一个更加智能的测试用例。

Python Mock 总结

即使对它的使用还有点不太熟悉，对单元测试来说，Python 的 mock 库可以说是一个规则改变者。我们已经演示了常见的用例来了解了 mock 在单元测试中的使用，希望这篇文章能够帮助 Python 开发者克服初期的障碍，写出优秀、经受过考验的代码。

via: https://www.toptal.com/python/an-introduction-to-mocking-in-python

作者：NAFTULI TZVI KAY 译者：cposture 校对：wxy

本文由 LCTT 原创翻译，Linux中国荣誉推出

使用 Docker Swarm 部署可扩展的 Python3 应用

Chad Lung 发布于 2016-08-24
另请参阅: 技术,Docker, Swarm
1 条评论

Ben Firshman 最近在 Dockercon 做了一个关于使用 Docker 构建无服务应用的演讲，你可以在这里查看详情（还有视频）。之后，我写了一篇关于如何使用 AWS Lambda 构建微服务系统的文章。

今天，我想展示给你的就是如何使用 Docker Swarm 部署一个简单的 Python Falcon REST 应用。这里我不会使用dockerrun 或者是其他无服务特性，你可能会惊讶，使用 Docker Swarm 部署（复制）一个 Python（Java、Go 都一样）应用是如此的简单。

注意：这展示的部分步骤是截取自 Swarm Tutorial，我已经修改了部分内容，并且增加了一个 Vagrant Helper 的仓库来启动一个可以让 Docker Swarm 工作起来的本地测试环境。请确保你使用的是 1.12 或以上版本的 Docker Engine。我写这篇文章的时候，使用的是 1.12RC2 版本。注意的是，这只是一个测试版本，可能还会有修改。

你要做的第一件事，就是如果你想本地运行的话，你要保证 Vagrant 已经正确的安装和运行了。你也可以按如下步骤使用你最喜欢的云服务提供商部署 Docker Swarm 虚拟机系统。

我们将会使用这三台 VM：一个简单的 Docker Swarm 管理平台和两台 worker。

安全注意事项：Vagrantfile 代码中包含了部分位于 Docker 测试服务器上的 shell 脚本。这是一个潜在的安全问题，它会运行你不能控制的脚本，所以请确保你会在运行代码之前审查过这部分的脚本。

$ git clone https://github.com/chadlung/vagrant-docker-swarm
$ cd vagrant-docker-swarm
$ vagrant plugin install vagrant-vbguest
$ vagrant up

Vagrant up 命令需要一些时间才能完成。

SSH 登录进入 manager1 虚拟机：

$ vagrant ssh manager1

在 manager1 的 ssh 终端会话中执行如下命令：

$ sudo docker swarm init --listen-addr 192.168.99.100:2377

现在还没有 worker 注册上来：

$ sudo docker node ls

让我们注册两个新的 worker，请打开两个新的终端会话（保持 manager1 会话继续运行）：

$ vagrant ssh worker1

在 worker1 的 ssh 终端会话上执行如下命令：

$ sudo docker swarm join 192.168.99.100:2377

在 worker2 的 ssh 终端会话上重复这些命令。

在 manager1 终端上执行如下命令：

$ docker node ls

你将会看到：

在 manager1 的终端里部署一个简单的服务。

sudo docker service create --replicas 1 --name pinger alpine ping google.com

这个命令将会部署一个服务，它会从 worker 之一 ping google.com。（或者 manager，manager 也可以运行服务，不过如果你只是想 worker 运行容器的话，也可以禁用这一点）。可以使用如下命令，查看哪些节点正在执行服务:

$ sudo docker service tasks pinger

结果会和这个比较类似：

所以，我们知道了服务正跑在 worker1 上。我们可以回到 worker1 的会话里，然后进入正在运行的容器：

$ sudo docker ps

你可以看到容器的 id 是: ae56769b9d4d，在我的例子中，我运行如下的代码：

$ sudo docker attach ae56769b9d4d

你可以按下 CTRL-C 来停止服务。

回到 manager1，然后移除这个 pinger 服务。

$ sudo docker service rm pinger

现在，我们将会部署可复制的 Python 应用。注意，为了保持文章的简洁，而且容易复制，所以部署的是一个简单的应用。

你需要做的第一件事就是将镜像放到 Docker Hub上，或者使用我已经上传的一个。这是一个简单的 Python 3 Falcon REST 应用。它有一个简单的入口: /hello 带一个 value 参数。

放在 chadlung/hello-app 上的 Python 代码看起来像这样：

import json
from wsgiref import simple_server

import falcon


class HelloResource(object):
    def on_get(self, req, resp):
        try:
            value = req.get_param('value')

            resp.content_type = 'application/json'
            resp.status = falcon.HTTP_200
            resp.body = json.dumps({'message': str(value)})
        except Exception as ex:
            resp.status = falcon.HTTP_500
            resp.body = str(ex)


if __name__ == '__main__':
    app = falcon.API()
    hello_resource = HelloResource()
    app.add_route('/hello', hello_resource)
    httpd = simple_server.make_server('0.0.0.0', 8080, app)
    httpd.serve_forever()

Dockerfile 很简单：

FROM python:3.4.4

RUN pip install -U pip
RUN pip install -U falcon

EXPOSE 8080

COPY . /hello-app
WORKDIR /hello-app

CMD ["python", "app.py"]

上面表示的意思很简单，如果你想，你可以在本地运行该进行来访问这个入口： http://127.0.0.1:8080/hello?value=Fred

这将返回如下结果：

{"message": "Fred"}

在 Docker Hub 上构建和部署这个 hello-app（修改成你自己的 Docker Hub 仓库或者使用这个）：

$ sudo docker build . -t chadlung/hello-app:2
$ sudo docker push chadlung/hello-app:2

现在，我们可以将应用部署到之前的 Docker Swarm 了。登录 manager1 的 ssh 终端会话，并且执行：

$ sudo docker service create -p 8080:8080 --replicas 2 --name hello-app chadlung/hello-app:2
$ sudo docker service inspect --pretty hello-app
$ sudo docker service tasks hello-app

现在，我们已经可以测试了。使用任何一个 Swarm 节点的 IP 来访问 /hello 入口。在本例中，我在 manager1 的终端里使用 curl 命令：

注意，Swarm 中的所有的 IP 都可以，不管这个服务是运行在一台还是更多的节点上。

$ curl -v -X GET "http://192.168.99.100:8080/hello?value=Chad"
$ curl -v -X GET "http://192.168.99.101:8080/hello?value=Test"
$ curl -v -X GET "http://192.168.99.102:8080/hello?value=Docker"

结果：

* Hostname was NOT found in DNS cache
*   Trying 192.168.99.101...
* Connected to 192.168.99.101 (192.168.99.101) port 8080 (#0)
> GET /hello?value=Chad HTTP/1.1
> User-Agent: curl/7.35.0
> Host: 192.168.99.101:8080
> Accept: */*
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Date: Tue, 28 Jun 2016 23:52:55 GMT
< Server: WSGIServer/0.2 CPython/3.4.4
< content-type: application/json
< content-length: 19
< 
{"message": "Chad"}

从浏览器中访问其他节点：

如果你想看运行的所有服务，你可以在 manager1 节点上运行如下代码：

$ sudo docker service ls

如果你想添加可视化控制平台，你可以安装 Docker Swarm Visualizer（这对于展示非常方便）。在 manager1 的终端中执行如下代码：

$ sudo docker run -it -d -p 5000:5000 -e HOST=192.168.99.100 -e PORT=5000 -v /var/run/docker.sock:/var/run/docker.sock manomarks/visualizer

打开你的浏览器，并且访问： http://192.168.99.100:5000/

结果如下（假设已经运行了两个 Docker Swarm 服务）：

要停止运行 hello-app（已经在两个节点上运行了），可以在 manager1 上执行这个代码：

$ sudo docker service rm hello-app

如果想停止 Visualizer，那么在 manager1 的终端中执行：

$ sudo docker ps

获得容器的 ID，这里是： f71fec0d3ce1，从 manager1 的终端会话中执行这个代码：

$ sudo docker stop f71fec0d3ce1

祝你成功使用 Docker Swarm。这篇文章主要是以 1.12 版本来进行描述的。

via: http://www.giantflyingsaucer.com/blog/?p=5923

作者：Chad Lung 译者：MikeCoder 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

Linux 内核里的数据结构——位数组

0xAX 发布于 2016-08-23
另请参阅: 软件开发,内核, 数据结构, 位数组
评论

Linux 内核中的位数组和位操作

除了不同的基于链式和树的数据结构以外，Linux 内核也为位数组（或称为位图（ bitmap ））提供了 API。位数组在 Linux 内核里被广泛使用，并且在以下的源代码文件中包含了与这样的结构搭配使用的通用 API：

除了这两个文件之外，还有体系结构特定的头文件，它们为特定的体系结构提供优化的位操作。我们将探讨 x86\_64 体系结构，因此在我们的例子里，它会是

arch/x86/include/asm/bitops.h

头文件。正如我上面所写的，位图在 Linux 内核中被广泛地使用。例如，位数组常常用于保存一组在线/离线处理器，以便系统支持热插拔的 CPU（你可以在 cpumasks 部分阅读更多相关知识），一个位数组（ bit array ）可以在 Linux 内核初始化等期间保存一组已分配的中断处理。

因此，本部分的主要目的是了解位数组（ bit array ）是如何在 Linux 内核中实现的。让我们现在开始吧。

位数组声明

在我们开始查看位图操作的 API 之前，我们必须知道如何在 Linux 内核中声明它。有两种声明位数组的通用方法。第一种简单的声明一个位数组的方法是，定义一个 unsigned long 的数组，例如：

unsigned long my_bitmap[8]

第二种方法，是使用 DECLARE_BITMAP 宏，它定义于 include/linux/types.h 头文件：

#define DECLARE_BITMAP(name,bits) \
    unsigned long name[BITS_TO_LONGS(bits)]

我们可以看到 DECLARE_BITMAP 宏使用两个参数：

name - 位图名称;
bits - 位图中位数;

并且只是使用 BITS_TO_LONGS(bits) 元素展开 unsigned long 数组的定义。 BITS_TO_LONGS 宏将一个给定的位数转换为 long 的个数，换言之，就是计算 bits 中有多少个 8 字节元素：

#define BITS_PER_BYTE           8
#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
#define BITS_TO_LONGS(nr)       DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long))

因此，例如 DECLARE_BITMAP(my_bitmap, 64) 将产生：

>>> (((64) + (64) - 1) / (64))
1

与：

unsigned long my_bitmap[1];

在能够声明一个位数组之后，我们便可以使用它了。

体系结构特定的位操作

我们已经看了上面提及的一对源文件和头文件，它们提供了位数组操作的 API。其中重要且广泛使用的位数组 API 是体系结构特定的且位于已提及的头文件中 arch/x86/include/asm/bitops.h。

首先让我们查看两个最重要的函数：

set_bit;
clear_bit.

我认为没有必要解释这些函数的作用。从它们的名字来看，这已经很清楚了。让我们直接查看它们的实现。如果你浏览 arch/x86/include/asm/bitops.h 头文件，你将会注意到这些函数中的每一个都有原子性和非原子性两种变体。在我们开始深入这些函数的实现之前，首先，我们必须了解一些有关原子（ atomic ）操作的知识。

简而言之，原子操作保证两个或以上的操作不会并发地执行同一数据。x86 体系结构提供了一系列原子指令，例如， xchg、cmpxchg 等指令。除了原子指令，一些非原子指令可以在 lock 指令的帮助下具有原子性。现在你已经对原子操作有了足够的了解，我们可以接着探讨 set_bit 和 clear_bit 函数的实现。

我们先考虑函数的非原子性（ non-atomic ）变体。非原子性的 set_bit 和 clear_bit 的名字以双下划线开始。正如我们所知道的，所有这些函数都定义于 arch/x86/include/asm/bitops.h 头文件，并且第一个函数就是 __set_bit:

static inline void __set_bit(long nr, volatile unsigned long *addr)
{
    asm volatile("bts %1,%0" : ADDR : "Ir" (nr) : "memory");
}

正如我们所看到的，它使用了两个参数：

nr - 位数组中的位号（LCTT 译注：从 0 开始）
addr - 我们需要置位的位数组地址

注意，addr 参数使用 volatile 关键字定义，以告诉编译器给定地址指向的变量可能会被修改。 __set_bit 的实现相当简单。正如我们所看到的，它仅包含一行内联汇编代码。在我们的例子中，我们使用 bts 指令，从位数组中选出一个第一操作数（我们的例子中的 nr）所指定的位，存储选出的位的值到 CF 标志寄存器并设置该位（LCTT 译注：即 nr 指定的位置为 1）。

注意，我们了解了 nr 的用法，但这里还有一个参数 addr 呢！你或许已经猜到秘密就在 ADDR。 ADDR 是一个定义在同一个头文件中的宏，它展开为一个包含给定地址和 +m 约束的字符串：

#define ADDR                BITOP_ADDR(addr)
#define BITOP_ADDR(x) "+m" (*(volatile long *) (x))

除了 +m 之外，在 __set_bit 函数中我们可以看到其他约束。让我们查看并试着理解它们所表示的意义：

+m - 表示内存操作数，这里的 + 表明给定的操作数为输入输出操作数；
I - 表示整型常量；
r - 表示寄存器操作数

除了这些约束之外，我们也能看到 memory 关键字，其告诉编译器这段代码会修改内存中的变量。到此为止，现在我们看看相同的原子性（ atomic ）变体函数。它看起来比非原子性（ non-atomic ）变体更加复杂：

static __always_inline void
set_bit(long nr, volatile unsigned long *addr)
{
    if (IS_IMMEDIATE(nr)) {
        asm volatile(LOCK_PREFIX "orb %1,%0"
            : CONST_MASK_ADDR(nr, addr)
            : "iq" ((u8)CONST_MASK(nr))
            : "memory");
    } else {
        asm volatile(LOCK_PREFIX "bts %1,%0"
            : BITOP_ADDR(addr) : "Ir" (nr) : "memory");
    }
}

（LCTT 译注：BITOP\_ADDR 的定义为：#define BITOP_ADDR(x) "=m" (*(volatile long *) (x))，ORB 为字节按位或。）

首先注意，这个函数使用了与 __set_bit 相同的参数集合，但额外地使用了 __always_inline 属性标记。 __always_inline 是一个定义于 include/linux/compiler-gcc.h 的宏，并且只是展开为 always_inline 属性：

#define __always_inline inline __attribute__((always_inline))

其意味着这个函数总是内联的，以减少 Linux 内核映像的大小。现在让我们试着了解下 set_bit 函数的实现。首先我们在 set_bit 函数的开头检查给定的位的数量。IS_IMMEDIATE 宏定义于相同的头文件，并展开为 gcc 内置函数的调用：

#define IS_IMMEDIATE(nr)        (__builtin_constant_p(nr))

如果给定的参数是编译期已知的常量，__builtin_constant_p 内置函数则返回 1，其他情况返回 0。假若给定的位数是编译期已知的常量，我们便无须使用效率低下的 bts 指令去设置位。我们可以只需在给定地址指向的字节上执行按位或操作，其字节包含给定的位，掩码位数表示高位为 1，其他位为 0 的掩码。在其他情况下，如果给定的位号不是编译期已知常量，我们便做和 __set_bit 函数一样的事。CONST_MASK_ADDR 宏：

#define CONST_MASK_ADDR(nr, addr)   BITOP_ADDR((void *)(addr) + ((nr)>>3))

展开为带有到包含给定位的字节偏移的给定地址，例如，我们拥有地址 0x1000 和位号 0x9。因为 0x9 代表 一个字节 + 一位，所以我们的地址是 addr + 1:

>>> hex(0x1000 + (0x9 >> 3))
'0x1001'

CONST_MASK 宏将我们给定的位号表示为字节，位号对应位为高位 1，其他位为 0：

#define CONST_MASK(nr)          (1 << ((nr) & 7))

>>> bin(1 << (0x9 & 7))
'0b10'

最后，我们应用 按位或 运算到这些变量上面，因此，假如我们的地址是 0x4097 ，并且我们需要置位号为 9 的位为 1：

>>> bin(0x4097)
'0b100000010010111'
>>> bin((0x4097 >> 0x9) | (1 << (0x9 & 7)))
'0b100010'

第 9 位 将会被置位。（LCTT 译注：这里的 9 是从 0 开始计数的，比如0010，按照作者的意思，其中的 1 是第 1 位）

注意，所有这些操作使用 LOCK_PREFIX 标记，其展开为 lock 指令，保证该操作的原子性。

正如我们所知，除了 set_bit 和 __set_bit 操作之外，Linux 内核还提供了两个功能相反的函数，在原子性和非原子性的上下文中清位。它们是 clear_bit 和 __clear_bit。这两个函数都定义于同一个头文件并且使用相同的参数集合。不仅参数相似，一般而言，这些函数与 set_bit 和 __set_bit 也非常相似。让我们查看非原子性 __clear_bit 的实现吧：

static inline void __clear_bit(long nr, volatile unsigned long *addr)
{
    asm volatile("btr %1,%0" : ADDR : "Ir" (nr));
}

没错，正如我们所见，__clear_bit 使用相同的参数集合，并包含极其相似的内联汇编代码块。它只是使用 btr 指令替换了 bts。正如我们从函数名所理解的一样，通过给定地址，它清除了给定的位。btr 指令表现得像 bts（LCTT 译注：原文这里为 btr，可能为笔误，修正为 bts）。该指令选出第一操作数所指定的位，存储它的值到 CF 标志寄存器，并且清除第二操作数指定的位数组中的对应位。

__clear_bit 的原子性变体为 clear_bit：

static __always_inline void
clear_bit(long nr, volatile unsigned long *addr)
{
    if (IS_IMMEDIATE(nr)) {
        asm volatile(LOCK_PREFIX "andb %1,%0"
            : CONST_MASK_ADDR(nr, addr)
            : "iq" ((u8)~CONST_MASK(nr)));
    } else {
        asm volatile(LOCK_PREFIX "btr %1,%0"
            : BITOP_ADDR(addr)
            : "Ir" (nr));
    }
}

并且正如我们所看到的，它与 set_bit 非常相似，只有两处不同。第一处差异为 clear_bit 使用 btr 指令来清位，而 set_bit 使用 bts 指令来置位。第二处差异为 clear_bit 使用否定的位掩码和 按位与 在给定的字节上置位，而 set_bit 使用 按位或 指令。

到此为止，我们可以在任意位数组置位和清位了，我们将看看位掩码上的其他操作。

在 Linux 内核中对位数组最广泛使用的操作是设置和清除位，但是除了这两个操作外，位数组上其他操作也是非常有用的。Linux 内核里另一种广泛使用的操作是知晓位数组中一个给定的位是否被置位。我们能够通过 test_bit 宏的帮助实现这一功能。这个宏定义于 arch/x86/include/asm/bitops.h 头文件，并根据位号分别展开为 constant_test_bit 或 variable_test_bit 调用。

#define test_bit(nr, addr)          \
    (__builtin_constant_p((nr))                 \
     ? constant_test_bit((nr), (addr))          \
     : variable_test_bit((nr), (addr)))

因此，如果 nr 是编译期已知常量，test_bit 将展开为 constant_test_bit 函数的调用，而其他情况则为 variable_test_bit。现在让我们看看这些函数的实现，让我们从 variable_test_bit 开始看起：

static inline int variable_test_bit(long nr, volatile const unsigned long *addr)
{
    int oldbit;

    asm volatile("bt %2,%1\n\t"
             "sbb %0,%0"
             : "=r" (oldbit)
             : "m" (*(unsigned long *)addr), "Ir" (nr));

    return oldbit;
}

variable_test_bit 函数使用了与 set_bit 及其他函数使用的相似的参数集合。我们也可以看到执行 bt 和 sbb 指令的内联汇编代码。bt （或称 bit test）指令从第二操作数指定的位数组选出第一操作数指定的一个指定位，并且将该位的值存进标志寄存器的 CF 位。第二个指令 sbb 从第二操作数中减去第一操作数，再减去 CF 的值。因此，这里将一个从给定位数组中的给定位号的值写进标志寄存器的 CF 位，并且执行 sbb 指令计算： 00000000 - CF，并将结果写进 oldbit 变量。

constant_test_bit 函数做了和我们在 set_bit 所看到的一样的事：

static __always_inline int constant_test_bit(long nr, const volatile unsigned long *addr)
{
    return ((1UL << (nr & (BITS_PER_LONG-1))) &
        (addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
}

它生成了一个位号对应位为高位 1，而其他位为 0 的字节（正如我们在 CONST_MASK 所看到的），并将按位与应用于包含给定位号的字节。

下一个被广泛使用的位数组相关操作是改变一个位数组中的位。为此，Linux 内核提供了两个辅助函数：

__change_bit;
change_bit.

你可能已经猜测到，就拿 set_bit 和 __set_bit 例子说，这两个变体分别是原子和非原子版本。首先，让我们看看 __change_bit 函数的实现：

static inline void __change_bit(long nr, volatile unsigned long *addr)
{
    asm volatile("btc %1,%0" : ADDR : "Ir" (nr));
}

相当简单，不是吗？ __change_bit 的实现和 __set_bit 一样，只是我们使用 btc 替换 bts 指令而已。该指令从一个给定位数组中选出一个给定位，将该为位的值存进 CF 并使用求反操作改变它的值，因此值为 1 的位将变为 0，反之亦然：

>>> int(not 1)
0
>>> int(not 0)
1

__change_bit 的原子版本为 change_bit 函数：

static inline void change_bit(long nr, volatile unsigned long *addr)
{
    if (IS_IMMEDIATE(nr)) {
        asm volatile(LOCK_PREFIX "xorb %1,%0"
            : CONST_MASK_ADDR(nr, addr)
            : "iq" ((u8)CONST_MASK(nr)));
    } else {
        asm volatile(LOCK_PREFIX "btc %1,%0"
            : BITOP_ADDR(addr)
            : "Ir" (nr));
    }
}

它和 set_bit 函数很相似，但也存在两点不同。第一处差异为 xor 操作而不是 or。第二处差异为 btc（ LCTT 译注：原文为 bts，为作者笔误）而不是 bts。

目前，我们了解了最重要的体系特定的位数组操作，是时候看看一般的位图 API 了。

通用位操作

除了 arch/x86/include/asm/bitops.h 中体系特定的 API 外，Linux 内核提供了操作位数组的通用 API。正如我们本部分开头所了解的一样，我们可以在 include/linux/bitmap.h 头文件和 lib/bitmap.c 源文件中找到它。但在查看这些源文件之前，我们先看看 include/linux/bitops.h 头文件，其提供了一系列有用的宏，让我们看看它们当中一部分。

首先我们看看以下 4 个宏：

for_each_set_bit
for_each_set_bit_from
for_each_clear_bit
for_each_clear_bit_from

所有这些宏都提供了遍历位数组中某些位集合的迭代器。第一个宏迭代那些被置位的位。第二个宏也是一样，但它是从某一个确定的位开始。最后两个宏做的一样，但是迭代那些被清位的位。让我们看看 for_each_set_bit 宏：

#define for_each_set_bit(bit, addr, size) \
    for ((bit) = find_first_bit((addr), (size));        \
         (bit) < (size);                    \
         (bit) = find_next_bit((addr), (size), (bit) + 1))

正如我们所看到的，它使用了三个参数，并展开为一个循环，该循环从作为 find_first_bit 函数返回结果的第一个置位开始，到小于给定大小的最后一个置位为止。

除了这四个宏， arch/x86/include/asm/bitops.h 也提供了 64-bit 或 32-bit 变量循环的 API 等等。

下一个头文件提供了操作位数组的 API。例如，它提供了以下两个函数：

bitmap_zero;
bitmap_fill.

它们分别可以清除一个位数组和用 1 填充位数组。让我们看看 bitmap_zero 函数的实现：

static inline void bitmap_zero(unsigned long *dst, unsigned int nbits)
{
    if (small_const_nbits(nbits))
        *dst = 0UL;
    else {
        unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
        memset(dst, 0, len);
    }
}

首先我们可以看到对 nbits 的检查。 small_const_nbits 是一个定义在同一个头文件的宏：

#define small_const_nbits(nbits) \
    (__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG)

正如我们可以看到的，它检查 nbits 是否为编译期已知常量，并且其值不超过 BITS_PER_LONG 或 64。如果位数目没有超过一个 long 变量的位数，我们可以仅仅设置为 0。在其他情况，我们需要计算有多少个需要填充位数组的 long 变量并且使用 memset 进行填充。

bitmap_fill 函数的实现和 biramp_zero 函数很相似，除了我们需要在给定的位数组中填写 0xff 或 0b11111111：

static inline void bitmap_fill(unsigned long *dst, unsigned int nbits)
{
    unsigned int nlongs = BITS_TO_LONGS(nbits);
    if (!small_const_nbits(nbits)) {
        unsigned int len = (nlongs - 1) * sizeof(unsigned long);
        memset(dst, 0xff,  len);
    }
    dst[nlongs - 1] = BITMAP_LAST_WORD_MASK(nbits);
}

除了 bitmap_fill 和 bitmap_zero，include/linux/bitmap.h 头文件也提供了和 bitmap_zero 很相似的 bitmap_copy，只是仅仅使用 memcpy 而不是 memset 这点差异而已。它也提供了位数组的按位操作，像 bitmap_and, bitmap_or, bitamp_xor等等。我们不会探讨这些函数的实现了，因为如果你理解了本部分的所有内容，这些函数的实现是很容易理解的。无论如何，如果你对这些函数是如何实现的感兴趣，你可以打开并研究 include/linux/bitmap.h 头文件。

本部分到此为止。

链接

via: https://github.com/0xAX/linux-insides/blob/master/DataStructures/bitmap.md

作者：0xAX 译者：cposture 校对：wxy

本文由 LCTT 原创翻译，Linux中国荣誉推出

LXD 2.0 系列（三）：你的第一个 LXD 容器

Stéphane Graber 发布于 2016-08-22
另请参阅: 容器与云,LXC, 容器, LXD
评论

这是 LXD 2.0 系列介绍文章的第三篇博客。

由于在管理 LXD 容器时涉及到大量的命令，所以这篇文章的篇幅是比较长的，如果你更喜欢使用同样的命令来快速的一步步实现整个过程，你可以尝试我们的在线示例！

创建并启动一个新的容器

正如我在先前的文章中提到的一样，LXD 命令行客户端预配置了几个镜像源。Ubuntu 的所有发行版和架构平台全都提供了官方镜像，但是对于其他的发行版也有大量的非官方镜像，那些镜像都是由社区制作并且被 LXC 上游贡献者所维护。

Ubuntu

如果你想要支持最为完善的 Ubuntu 版本，你可以按照下面的去做：

lxc launch ubuntu:

注意，这里意味着会随着 Ubuntu LTS 的发布而变化。因此，如果用于脚本，你需要指明你具体安装的版本（参见下面）。

Ubuntu14.04 LTS

得到最新更新的、已经测试过的、稳定的 Ubuntu 14.04 LTS 镜像，你可以简单的执行：

lxc launch ubuntu:14.04

在该模式下，会指定一个随机的容器名。

如果你更喜欢指定一个你自己的名字，你可以这样做：

lxc launch ubuntu:14.04 c1

如果你想要指定一个特定的体系架构（非主流平台），比如 32 位 Intel 镜像，你可以这样做：

lxc launch ubuntu:14.04/i386 c2

当前的 Ubuntu 开发版本

上面使用的“ubuntu:”远程仓库只会给你提供官方的并经过测试的 Ubuntu 镜像。但是如果你想要未经测试过的日常构建版本，开发版可能对你来说是合适的，你需要使用“ubuntu-daily:”远程仓库。

lxc launch ubuntu-daily:devel c3

在这个例子中，将会自动选中最新的 Ubuntu 开发版本。

你也可以更加精确，比如你可以使用代号名：

lxc launch ubuntu-daily:xenial c4

其他

全部的 Ubuntu 镜像列表可以这样获得：

lxc image list ubuntu:
lxc image list ubuntu-daily:

全部的非官方镜像：

lxc image list images:

某个给定的原程仓库的全部别名（易记名称）可以这样获得（比如对于“ubuntu:”远程仓库）：

lxc image alias list ubuntu:

创建但不启动一个容器

如果你想创建一个容器或者一批容器，但是你不想马上启动它们，你可以使用lxc init替换掉lxc launch。所有的选项都是相同的，唯一的不同就是它并不会在你创建完成之后启动容器。

lxc init ubuntu:

关于你的容器的信息

列出所有的容器

要列出你的所有容器，你可以这样这做：

lxc list

有大量的选项供你选择来改变被显示出来的列。在一个拥有大量容器的系统上，默认显示的列可能会有点慢（因为必须获取容器中的网络信息），你可以这样做来避免这种情况：

lxc list --fast

上面的命令显示了另外一套列的组合，这个组合在服务器端需要处理的信息更少。

你也可以基于名字或者属性来过滤掉一些东西：

stgraber@dakara:~$ lxc list security.privileged=true
+------+---------+---------------------+-----------------------------------------------+------------+-----------+
| NAME |  STATE  |        IPV4         |                       IPV6                    |    TYPE    | SNAPSHOTS |
+------+---------+---------------------+-----------------------------------------------+------------+-----------+
| suse | RUNNING | 172.17.0.105 (eth0) | 2607:f2c0:f00f:2700:216:3eff:fef2:aff4 (eth0) | PERSISTENT | 0         |
+------+---------+---------------------+-----------------------------------------------+------------+-----------+

在这个例子中，只有那些特权容器（禁用了用户命名空间）才会被列出来。

stgraber@dakara:~$ lxc list --fast alpine
+-------------+---------+--------------+----------------------+----------+------------+
|    NAME     |  STATE  | ARCHITECTURE |      CREATED AT      | PROFILES |    TYPE    |
+-------------+---------+--------------+----------------------+----------+------------+
| alpine      | RUNNING | x86_64       | 2016/03/20 02:11 UTC | default  | PERSISTENT |
+-------------+---------+--------------+----------------------+----------+------------+
| alpine-edge | RUNNING | x86_64       | 2016/03/20 02:19 UTC | default  | PERSISTENT |
+-------------+---------+--------------+----------------------+----------+------------+

在这个例子中，只有在名字中带有“alpine”的容器才会被列出来（也支持复杂的正则表达式）。

获取容器的详细信息

由于 list 命令显然不能以一种友好的可读方式显示容器的所有信息，因此你可以使用如下方式来查询单个容器的信息：

lxc info <container>

例如：

stgraber@dakara:~$ lxc info zerotier
Name: zerotier
Architecture: x86_64
Created: 2016/02/20 20:01 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 31715
Processes: 32
Ips:
 eth0: inet 172.17.0.101
 eth0: inet6 2607:f2c0:f00f:2700:216:3eff:feec:65a8
 eth0: inet6 fe80::216:3eff:feec:65a8
 lo: inet 127.0.0.1
 lo: inet6 ::1
 lxcbr0: inet 10.0.3.1
 lxcbr0: inet6 fe80::c0a4:ceff:fe52:4d51
 zt0: inet 29.17.181.59
 zt0: inet6 fd80:56c2:e21c:0:199:9379:e711:b3e1
 zt0: inet6 fe80::79:e7ff:fe0d:5123
Snapshots:
 zerotier/blah (taken at 2016/03/08 23:55 UTC) (stateless)

生命周期管理命令

这些命令对于任何容器或者虚拟机管理器或许都是最普通的命令，但是它们仍然需要讲到。

所有的这些命令在批量操作时都能接受多个容器名。

启动

启动一个容器就向下面一样简单：

lxc start <container>

停止

停止一个容器可以这样来完成：

lxc stop <container>

如果容器不合作（即没有对发出的 SIGPWR 信号产生回应），这时候，你可以使用下面的方式强制执行：

lxc stop <container> --force

重启

通过下面的命令来重启一个容器：

lxc restart <container>

如果容器不合作（即没有对发出的 SIGINT 信号产生回应），你可以使用下面的方式强制执行：

lxc restart <container> --force

暂停

你也可以“暂停”一个容器，在这种模式下，所有的容器任务将会被发送相同的 SIGSTOP 信号，这也意味着它们将仍然是可见的，并且仍然会占用内存，但是它们不会从调度程序中得到任何的 CPU 时间片。

如果你有一个很占用 CPU 的容器，而这个容器需要一点时间来启动，但是你却并不会经常用到它。这时候，你可以先启动它，然后将它暂停，并在你需要它的时候再启动它。

lxc pause <container>

删除

最后，如果你不需要这个容器了，你可以用下面的命令删除它：

lxc delete <container>

注意，如果容器还处于运行状态时你将必须使用“-force”。

容器的配置

LXD 拥有大量的容器配置设定，包括资源限制，容器启动控制以及对各种设备是否允许访问的配置选项。完整的清单因为太长所以并没有在本文中列出，但是，你可以从[这里]获取它。

就设备而言，LXD 当前支持下面列出的这些设备类型：

磁盘既可以是一块物理磁盘，也可以只是一个被挂挂载到容器上的分区，还可以是一个来自主机的绑定挂载路径。
网络接口卡一块网卡。它可以是一块桥接的虚拟网卡，或者是一块点对点设备，还可以是一块以太局域网设备或者一块已经被连接到容器的真实物理接口。
unix 块设备一个 UNIX 块设备，比如 /dev/sda
unix 字符设备一个 UNIX 字符设备，比如 /dev/kvm
none 这种特殊类型被用来隐藏那种可以通过配置文件被继承的设备。

配置 profile 文件

所有可用的配置文件列表可以这样获取：

lxc profile list

为了看到给定配置文件的内容，最简单的方式是这样做：

lxc profile show <profile>

你可能想要改变文件里面的内容，可以这样做：

lxc profile edit <profile>

你可以使用如下命令来改变应用到给定容器的配置文件列表：

lxc profile apply <container> <profile1>,<profile2>,<profile3>,...

本地配置

有些配置是某个容器特定的，你并不想将它放到配置文件中，你可直接对容器设置它们：

lxc config edit <container>

上面的命令做的和“profile edit”命令是一样。

如果不想在文本编辑器中打开整个文件的内容，你也可以像这样修改单独的配置：

lxc config set <container> <key> <value>

或者添加设备，例如：

lxc config device add my-container kvm unix-char path=/dev/kvm

上面的命令将会为名为“my-container”的容器设置一个 /dev/kvm 项。

对一个配置文件使用lxc profile set和lxc profile device add命令也能实现上面的功能。

读取配置

你可以使用如下命令来读取容器的本地配置：

lxc config show <container>

或者得到已经被展开了的配置（包含了所有的配置值）：

lxc config show --expanded <container>

例如：

stgraber@dakara:~$ lxc config show --expanded zerotier
name: zerotier
profiles:
- default
config:
 security.nesting: "true"
 user.a: b
 volatile.base_image: a49d26ce5808075f5175bf31f5cb90561f5023dcd408da8ac5e834096d46b2d8
 volatile.eth0.hwaddr: 00:16:3e:ec:65:a8
 volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
devices:
 eth0:
  name: eth0
  nictype: macvlan
  parent: eth0
  type: nic
  limits.ingress: 10Mbit
  limits.egress: 10Mbit
 root:
  path: /
  size: 30GB
  type: disk
 tun:
  path: /dev/net/tun
  type: unix-char
ephemeral: false

这样做可以很方便的检查有哪些配置属性被应用到了给定的容器。

实时配置更新

注意，除非在文档中已经被明确指出，否则所有的配置值和设备项的设置都会对容器实时发生影响。这意味着在不重启正在运行的容器的情况下，你可以添加和移除某些设备或者修改安全配置文件。

获得一个 shell

LXD 允许你直接在容器中执行任务。最常用的做法是在容器中得到一个 shell 或者执行一些管理员任务。

和 SSH 相比，这样做的好处是你不需要容器是网络可达的，也不需要任何软件和特定的配置。

执行环境

与 LXD 在容器内执行命令的方式相比，有一点是不同的，那就是 shell 并不是在容器中运行。这也意味着容器不知道使用的是什么样的 shell，以及设置了什么样的环境变量和你的家目录在哪里。

通过 LXD 来执行命令总是使用最小的路径环境变量设置，并且 HOME 环境变量必定为 /root，以容器的超级用户身份来执行（即 uid 为 0，gid 为 0）。

其他的环境变量可以通过命令行来设置，或者在“environment.”配置中设置成永久环境变量。

执行命令

在容器中获得一个 shell 可以简单的执行下列命令得到：

lxc exec <container> bash

当然，这样做的前提是容器内已经安装了 bash。

更复杂的命令要求使用分隔符来合理分隔参数。

lxc exec <container> -- ls -lh /

如果想要设置或者重写变量，你可以使用“-env”参数，例如：

stgraber@dakara:~$ lxc exec zerotier --env mykey=myvalue env | grep mykey
mykey=myvalue

管理文件

因为 LXD 可以直接访问容器的文件系统，因此，它可以直接读取和写入容器中的任意文件。当我们需要提取日志文件或者与容器传递文件时，这个特性是很有用的。

从容器中取回一个文件

想要从容器中获得一个文件，简单的执行下列命令：

lxc file pull <container>/<path> <dest>

例如：

stgraber@dakara:~$ lxc file pull zerotier/etc/hosts hosts

或者将它读取到标准输出：

stgraber@dakara:~$ lxc file pull zerotier/etc/hosts -
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

向容器发送一个文件

发送以另一种简单的方式完成：

lxc file push <source> <container>/<path>

直接编辑一个文件

编辑是一个方便的功能，其实就是简单的提取一个给定的路径，在你的默认文本编辑器中打开它，在你关闭编辑器时会自动将编辑的内容保存到容器。

lxc file edit <container>/<path>

快照管理

LXD 允许你对容器执行快照功能并恢复它。快照包括了容器在某一时刻的完整状态（如果-stateful被使用的话将会包括运行状态），这也意味着所有的容器配置，容器设备和容器文件系统也会被保存。

创建一个快照

你可以使用下面的命令来执行快照功能：

lxc snapshot <container>

命令执行完成之后将会生成名为snapX（X 为一个自动增长的数）的记录。

除此之外，你还可以使用如下命令命名你的快照：

lxc snapshot <container> <snapshot name>

列出所有的快照

一个容器的所有快照的数量可以使用lxc list来得到，但是具体的快照列表只能执行lxc info命令才能看到。

lxc info <container>

恢复快照

为了恢复快照，你可以简单的执行下面的命令：

lxc restore <container> <snapshot name>

给快照重命名

可以使用如下命令来给快照重命名：

lxc move <container>/<snapshot name> <container>/<new snapshot name>

从快照中创建一个新的容器

你可以使用快照来创建一个新的容器，而这个新的容器除了一些可变的信息将会被重置之外（例如 MAC 地址）其余所有信息都将和快照完全相同。

lxc copy <source container>/<snapshot name> <destination container>

删除一个快照

最后，你可以执行下面的命令来删除一个快照：

lxc delete <container>/<snapshot name>

克隆并重命名

得到一个纯净的发行版镜像总是让人感到愉悦，但是，有时候你想要安装一系列的软件到你的容器中，这时，你需要配置它然后将它分支成多个其他的容器。

复制一个容器

为了复制一个容器并有效的将它克隆到一个新的容器中，你可以执行下面的命令：

lxc copy <source container> <destination container>

目标容器在所有方面将会完全和源容器等同。除了新的容器没有任何源容器的快照以及一些可变值将会被重置之外（例如 MAC 地址）。

移动一个快照

LXD 允许你复制容器并在主机之间移动它。但是，关于这一点将在后面的文章中介绍。

现在，“move”命令将会被用作给容器重命名。

lxc move <old name> <new name>

唯一的要求就是当容器应该被停止，容器内的任何事情都会被保存成它本来的样子，包括可变化的信息（类似 MAC 地址等）。

结论

这篇如此长的文章介绍了大多数你可能会在日常操作中使用到的命令。

很显然，这些如此之多的命令都会有不少选项，可以让你的命令更加有效率，或者可以让你指定你的 LXD 容器的某个具体方面。最好的学习这些命令的方式就是深入学习它们的帮助文档（ -help）。

Fabric - 通过 SSH 来自动化管理 Linux 任务和布署应用

Aaron Kili 发布于 2016-08-22
另请参阅: 系统运维,SSH, Fabric, 远程, 自动化
2 条评论

当要管理远程机器或者要布署应用时，虽然你有多种命令行工具可以选择，但是其中很多工具都缺少详细的使用文档。

在这篇教程中，我们将会一步一步地向你介绍如何使用 fabric 来帮助你更好得管理多台服务器。

使用 Fabric 来自动化地管理 Linux 任务

Fabric 是一个用 Python 编写的命令行工具库，它可以帮助系统管理员高效地执行某些任务，比如通过 SSH 到多台机器上执行某些命令，远程布署应用等。

在使用之前，如果你拥有使用 Python 的经验能帮你更好的使用 Fabric。当然，如果没有那也不影响使用 Fabric。

我们为什么要选择 Fabric：

简单
完备的文档
如果你会 Python，不用增加学习其他语言的成本
易于安装使用
使用便捷
支持多台机器并行操作

在 Linux 上如何安装 Fabric

Fabric 有一个特点就是要远程操作的机器只需要支持标准的 OpenSSH 服务即可。只要保证在机器上安装并开启了这个服务就能使用 Fabric 来管理机器。

依赖

Python 2.5 或更新版本，以及对应的开发组件
Python-setuptools 和 pip（可选，但是非常推荐）gcc

我们推荐使用 pip 安装 Fabric，但是你也可以使用系统自带的包管理器如 yum, dnf 或 apt-get 来安装，包名一般是 fabric 或 python-fabric。

如果是基于 RHEL/CentOS 的发行版本的系统，你可以使用系统自带的 EPEL 源来安装 fabric。

# yum install fabric   [适用于基于 RedHat 系统]
# dnf install fabric   [适用于 Fedora 22+ 版本]

如果你是 Debian 或者其派生的系统如 Ubuntu 和 Mint 的用户，你可以使用 apt-get 来安装，如下所示：

# apt-get install fabric

如果你要安装开发版的 Fabric，你需要安装 pip 来安装 master 分支上最新版本。

# yum install python-pip       [适用于基于 RedHat 系统]
# dnf install python-pip       [适用于Fedora 22+ 版本]
# apt-get install python-pip   [适用于基于 Debian 系统]

安装好 pip 后，你可以使用 pip 获取最新版本的 Fabric。

# pip install fabric

如何使用 Fabric 来自动化管理 Linux 任务

现在我们来开始使用 Fabric，在之前的安装的过程中，Fabric Python 脚本已经被放到我们的系统目录，当我们要运行 Fabric 时输入 fab 命令即可。

在本地 Linux 机器上运行命令行

按照惯例，先用你喜欢的编辑器创建一个名为 fabfile.py 的 Python 脚本。你可以使用其他名字来命名脚本，但是就需要指定这个脚本的路径，如下所示：

# fabric --fabfile /path/to/the/file.py

Fabric 使用 fabfile.py 来执行任务，这个文件应该放在你执行 Fabric 命令的目录里面。

例子 1：创建入门的 Hello World 任务：

# vi fabfile.py

在文件内输入如下内容：

def hello():
    print('Hello world, Tecmint community')

保存文件并执行以下命令：

# fab hello

Fabric 工具使用说明

例子 2：新建一个名为 fabfile.py 的文件并打开：

粘贴以下代码至文件：

#!  /usr/bin/env python
from fabric.api import local
def uptime():
    local('uptime')

保存文件并执行以下命令：

# fab uptime

Fabric: 检查系统运行时间

让我们看看这个例子，fabfile.py 文件在本机执行了 uptime 这个命令。

在远程 Linux 机器上运行命令来执行自动化任务

Fabric API 使用了一个名为 env 的关联数组（Python 中的词典）作为配置目录，来储存 Fabric 要控制的机器的相关信息。

env.hosts 是一个用来存储你要执行 Fabric 任务的机器的列表，如果你的 IP 地址是 192.168.0.0，想要用 Fabric 来管理地址为 192.168.0.2 和 192.168.0.6 的机器，需要的配置如下所示：

#!/usr/bin/env python
from fabric.api import env
    env.hosts = [ '192.168.0.2', '192.168.0.6' ]

上面这几行代码只是声明了你要执行 Fabric 任务的主机地址，但是实际上并没有执行任何任务，下面我们就来定义一些任务。Fabric 提供了一系列可以与远程服务器交互的方法。

Fabric 提供了众多的方法，这里列出几个经常会用到的：

run - 可以在远程机器上运行的 shell 命令
local - 可以在本机上运行的 shell 命令
sudo - 使用 root 权限在远程机器上运行的 shell 命令
get - 从远程机器上下载一个或多个文件
put - 上传一个或多个文件到远程机器

例子 3：在多台机子上输出信息，新建新的 fabfile.py 文件如下所示

#!/usr/bin/env python
from fabric.api import env, run
env.hosts = ['192.168.0.2','192.168.0.6']
def echo():
    run("echo -n 'Hello, you are tuned to Tecmint ' ")

运行以下命令执行 Fabric 任务

# fab echo

fabric: 自动在远程 Linux 机器上执行任务

例子 4：你可以继续改进之前创建的执行 uptime 任务的 fabfile.py 文件，让它可以在多台服务器上运行 uptime 命令，也可以检查其磁盘使用情况，如下所示：

#!/usr/bin/env python
from fabric.api import env, run
env.hosts = ['192.168.0.2','192.168.0.6']
def uptime():
    run('uptime')
def disk_space():
    run('df -h')

保存并执行以下命令

# fab uptime
# fab disk_space

Fabric：自动在多台服务器上执行任务

在远程服务器上自动化布署 LAMP

例子 5：我们来尝试一下在远程服务器上布署 LAMP（Linux, Apache, MySQL/MariaDB and PHP）

我们要写个函数在远程使用 root 权限安装 LAMP。

在 RHEL/CentOS 或 Fedora 上

#!/usr/bin/env python
from fabric.api import env, run
env.hosts = ['192.168.0.2','192.168.0.6']
def deploy_lamp():
    run ("yum install -y httpd mariadb-server php php-mysql")

在 Debian/Ubuntu 或 Linux Mint 上

#!/usr/bin/env python
from fabric.api import env, run
env.hosts = ['192.168.0.2','192.168.0.6']
def deploy_lamp():
    sudo("apt-get install -q apache2 mysql-server libapache2-mod-php5 php5-mysql")

保存并执行以下命令：

# fab deploy_lamp

注：由于安装时会输出大量信息，这个例子我们就不提供屏幕 gif 图了

现在你可以使用 Fabric 和上文例子所示的功能来自动化的管理 Linux 服务器上的任务了。

一些 Fabric 有用的选项

你可以运行 fab -help 输出帮助信息，里面列出了所有可以使用的命令行信息
–fabfile=PATH 选项可以让你定义除了名为 fabfile.py 之外的模块
如果你想用指定的用户名登录远程主机，请使用 -user=USER 选项
如果你需要密码进行验证或者 sudo 提权，请使用 –password=PASSWORD 选项
如果需要输出某个命令的详细信息，请使用 –display=命令名 选项
使用 --list 输出所有可用的任务
使用 --list-format=FORMAT 选项能格式化 -list 选项输出的信息，可选的有 short、normal、 nested
--config=PATH 选项可以指定读取配置文件的地址
-–colorize-errors 能显示彩色的错误输出信息
--version 输出当前版本

总结

Fabric 是一个强大并且文档完备的工具，对于新手来说也能很快上手，阅读提供的文档能帮助你更好的了解它。如果你在安装和使用 Fabric 时发现什么问题可以在评论区留言，我们会及时回复。

参考：Fabric 文档

via: http://www.tecmint.com/automating-linux-system-administration-tasks/

作者：Aaron Kili 译者：NearTan 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出