分类 技术 下的文章

Google 最有趣的部分之一就是我们规模庞大的持续分析服务。我们可以看到谁在使用 CPU 和内存,我们可以持续地监控我们的生产服务以争用和阻止配置文件,并且我们可以生成分析和报告,并轻松地告诉我们可以进行哪些有重要影响的优化。

我简单研究了 Stackdriver Profiler,这是我们的新产品,它填补了针对云端用户在云服务范围内分析服务的空白。请注意,你无需在 Google 云平台上运行你的代码即可使用它。实际上,我现在每天都在开发时使用它。它也支持 Java 和 Node.js。

在生产中分析

pprof 可安全地用于生产。我们针对 CPU 和堆分配分析的额外会增加 5% 的开销。一个实例中每分钟收集 10 秒。如果你有一个 Kubernetes Pod 的多个副本,我们确保进行分摊收集。例如,如果你拥有一个 pod 的 10 个副本,模式,那么开销将变为 0.5%。这使用户可以一直进行分析。

我们目前支持 Go 程序的 CPU、堆、互斥和线程分析。

为什么?

在解释如何在生产中使用分析器之前,先解释为什么你想要在生产中进行分析将有所帮助。一些非常常见的情况是:

  • 调试仅在生产中可见的性能问题。
  • 了解 CPU 使用率以减少费用。
  • 了解争用的累积和优化的地方。
  • 了解新版本的影响,例如看到 canary 和产品级之间的区别。
  • 通过关联分析样本以了解延迟的根本原因来丰富你的分布式经验。

启用

Stackdriver Profiler 不能与 net/http/pprof 处理程序一起使用,并要求你在程序中安装和配置一个一行的代理。

go get cloud.google.com/go/profiler

在你的主函数中,启动分析器:

if err := profiler.Start(profiler.Config{
   Service:        "indexing-service",
   ServiceVersion: "1.0",
   ProjectID:      "bamboo-project-606", // optional on GCP
}); err != nil {
   log.Fatalf("Cannot start the profiler: %v", err) 
}

当你运行你的程序后,profiler 包将每分钟报告给分析器 10 秒钟。

可视化

当分析被报告给后端后,你将在 https://console.cloud.google.com/profiler 上看到火焰图。你可以按标签过滤并更改时间范围,也可以按服务名称和版本进行细分。数据将会长达 30 天。

你可以选择其中一个分析,按服务,区域和版本分解。你可以在火焰中移动并通过标签进行过滤。

阅读火焰图

Brendan Gregg 非常全面地解释了火焰图可视化。Stackdriver Profiler 增加了一点它自己的特点。

我们将查看一个 CPU 分析,但这也适用于其他分析。

  1. 最上面的 x 轴表示整个程序。火焰上的每个框表示调用路径上的一帧。框的宽度与执行该函数花费的 CPU 时间成正比。
  2. 框从左到右排序,左边是花费最多的调用路径。
  3. 来自同一包的帧具有相同的颜色。这里所有运行时功能均以绿色表示。
  4. 你可以单击任何框进一步展开执行树。

你可以将鼠标悬停在任何框上查看任何帧的详细信息。

过滤

你可以显示、隐藏和高亮符号名称。如果你特别想了解某个特定调用或包的消耗,这些信息非常有用。

  1. 选择你的过滤器。你可以组合多个过滤器。在这里,我们将高亮显示 runtime.memmove
  2. 火焰将使用过滤器过滤帧并可视化过滤后的框。在这种情况下,它高亮显示所有 runtime.memmove 框。

via: https://medium.com/google-cloud/continuous-profiling-of-go-programs-96d4416af77b

作者:JBD 译者:geekpi 校对:wxy

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

Docker 平台和容器已经成为打包、部署、和管理应用程序的标准。为了在一个集群内协调跨节点的容器,必须有一个关键的能力:一个容器编排器。

container orchestrator

对于关键的集群化以及计划的任务,编排器是起重大作用的,比如:

  • 管理容器计划和资源分配。
  • 支持服务发现和无缝的应用程序部署。
  • 分配应用程序运行必需的资源。

不幸的是,在这种环境下,编排器的分布式特性和资源的短暂性使得确保编排器的安全是一个极具挑战性的任务。在这篇文章中,我们将讨论容器编排器安全模型中没有考虑到的、但是很重要的这方面的详细情况,以及 Docker 企业版中如何使用内置的编排性能、Swarm 模式,去克服这些问题。

诱因和威胁模型

使用 swarm 模式的 Docker 企业版的其中一个主要目标是提供一个内置安全特性的编排器。为达到这个目标,我们部署了第一个在我们心目中认为的以最小权限原则设计的容器编排器。

在计算机科学中,一个分布式系统所要求的最小权限原则是,系统中的每个参与者仅仅能访问它正当目的所需要的信息和资源。不是更多,也不是更少。

“一个进程必须仅仅能去访问它的正当目的所需要的信息和资源”

最小权限原则

在一个 Docker 企业版集群中的每个节点分配的角色:既不是管理者(manager),也不是工人(worker)。这些角色为节点定义了一个很粗粒度的权限级别:分别进行管理和任务执行。尽管如此,不用理会它的角色,通过使用加密的方式,来保证一个节点仅仅有执行它的任务所需要的信息和资源。结果是,确保集群安全变得更容易了,甚至可以防止大多数的有经验的攻击者模式:攻击者控制了底层通讯网络,或者甚至攻陷了集群节点。

内核缺省安全

这是一个很老的安全最大化状态:如果它不是缺省的,就没人用它。Docker Swarm 模式将缺省安全这一概念融入了核心,并且使用这一机制去解决编排器生命周期中三个很难并且很重要的部分:

  1. 可信引导和节点引入。
  2. 节点身份发布和管理。
  3. 认证、授权和加密的信息存储和传播。

我们来分别看一下这三个部分:

可信引导和节点引入

确保集群安全的第一步,没有别的,就是严格控制成员和身份。管理员不能依赖它们节点的身份,并且在节点之间强制实行绝对的负载隔离。这意味着,未授权的节点不能允许加入到集群中,并且,已经是集群一部分的节点不能改变身份,突然去伪装成另一个节点。

为解决这种情况,通过 Docker 企业版 Swarm 模式管理的节点,维护了健壮的、不可改变的身份。期望的特性是,通过使用两种关键的构建块去保证加密:

  1. 为集群成员使用 安全加入令牌 Secure join token
  2. 从一个集中化的认证机构发行的内嵌唯一身份的证书。
加入 Swarm

要加入 Swarm,节点需要一份 安全加入令牌 Secure join token 的副本。在集群内的每个操作角色的令牌都是独一无二的 —— 现在有两种类型的节点:工人(workers)和管理者(managers)。由于这种区分,拥有一个工人令牌的节点将不允许以管理者角色加入到集群。唯一得到这个特殊令牌的方式是通过 swarm 的管理 API 去向集群管理者请求一个。

令牌是安全的并且是随机生成的,它还有一个使得令牌泄露更容易被检测到的特殊语法:一个可以在你的日志和仓库中很容易监视的特殊前缀。幸运的是,即便发现一个泄露,令牌也可以很容易去更新,并且,推荐你经常去更新它们 —— 特别是,在一段时间中你的集群不进行扩大的情况下。

Docker Swarm

引导信任

作为它的身份标识创建的一部分,一个新的节点将向任意一个网络管理者请求发布一个新的身份。但是,在我们下面的威胁模型中,所有的通讯可以被一个第三方拦截。这种请求存在的问题是:一个节点怎么知道与它进行对话的对方是合法的管理者?

Docker Security

幸运的是,Docker 有一个内置机制可以避免这种情况。这个加入令牌被主机用于加入 Swarm,包含了一个根 CA 证书的哈希串。所以,主机可以使用单向 TLS,并且使用这个哈希串去验证它加入的 Swarm 是否正确:如果管理者持有的证书没有被正确的 CA 哈希串签名,节点就知道它不可信任。

节点身份发布和管理

在一个 Swarm 中,身份标识是内嵌在每个节点都单独持有的一个 x509 证书中。在一个最小权限原则的表现形式中,证书的私钥被绝对限制在主机的原始位置。尤其是,管理者不能访问除了它自己的私钥以外的任何一个私钥。

身份发布

要接收它们的证书而无需共享它们的私钥,新的主机通过发布一个证书签名请求(CSR)来开始,管理者收到证书签名请求之后,转换成一个证书。这个证书成为这个新的主机的身份标识,使这个节点成为 Swarm 的一个完全合格成员!

当和安全引导机制一起使用时,发行身份标识的这个机制来加入节点是缺省安全的:所有的通讯部分都是经过认证的、授权的,并且非敏感信息从来都不会以明文方式进行交换。

身份标识延期

尽管如此,给一个 Swarm 中安全地加入节点,仅仅是 “故事” 的一部分。为降低证书的泄露或者失窃造成的影响,并且移除管理 CRL 列表的复杂性,Swarm 模式为身份标识使用了较短存活周期的证书。这些证书缺省情况下三个月后将过期,但是,也可以配置为一个小时后即刻过期!

Docker secrets

较短的证书过期时间意味着不能手动去处理证书更新,所以,通常会使用一个 PKI 系统。对于 Swarm,所有的证书是以一种不中断的方式进行自动更新的。这个过程很简单:使用一个相互认证的 TLS 连接去证明一个特定身份标识的所有者,一个 Swarm 节点定期生成一个新的公钥/私钥密钥对,并且用相关的 CSR 去签名发送,创建一个维持相同身份标识的完整的新证书。

经过认证、授权、和加密的信息存储和传播。

在一个正常的 Swarm 的操作中,关于任务的信息被发送给去运行的工人(worker)节点。这里不仅仅包含将被一个节点运行的容器的信息;也包含那个容器运行所必需的资源的所有信息,包括敏感的机密信息,比如,私钥、密码和 API 令牌。

传输安全

事实上,参与 Swarm 的每个节点都拥有一个独一无二的 X509 格式的证书,因此,节点之间的通讯安全是没有问题的:节点使用它们各自的证书,与另一个连接方进行相互认证、继承机密、真实性、和 TLS 的完整性。

Swarm Mode

关于 Swarm 模式的一个有趣的细节是,本质上它是使用了一个推送模式:仅管理者被允许去发送信息到工人们(workers)—— 显著降低了暴露在低权限的工人节点面前的管理者节点的攻击面。

将负载严格隔离进安全区域

管理者节点的其中一个责任是,去决定发送到每个工人(worker)节点的任务是什么。管理者节点使用多种策略去做这个决定;根据每个节点和每个负载的特性,去跨 Swarm 去安排负载。

在使用 Swarm 模式的 Docker 企业版中,管理者节点通过使用附加到每个单个节点标识上的安全标签,去影响这些安排决定。这些标签允许管理者将节点组与不同的安全区域连接到一起,以限制敏感负载暴露,以及使相关机密信息更安全。

Docker Swarm Security

安全分发机密

除了加快身份标识发布过程之外,管理者节点还有存储和分发工人节点所需要的任何资源的任务。机密信息像任何其它类型的资源一样处理,并且基于安全的 mTLS 连接,从管理者推送到工人节点。

Docker Secrets

在主机上,Docker 企业版能确保机密仅提供给它们指定的容器。在同一个主机上的其它容器并不能访问它们。Docker 以一个临时文件系统的方式显露机密给一个容器,确保机密总是保存在内存中,并且从不写入到磁盘。这种方式比其它竞争的替代者更加安全,比如,在环境变量中存储它们。一旦这个任务完成,这个机密将永远消失。

存储机密

在管理者主机上的机密总是保持加密的。缺省情况下,加密这些机密的密钥(被称为数据加密密钥,DEK)是以明文的方式存储在硬盘上的。这使得那些对安全性要求较低的人可以轻松地去使用 Docker Swarm 模式。

但是,如果你运行一个生产集群,我们推荐你启用自动锁定模式。当自动锁定模式启用后,一个重新更新过的 DEK 被一个独立的加密密钥的密钥(KEK)所加密。这个密钥从不被存储在集群中;管理者有责任将它存储在一个安全可靠的地方,并且当集群启动的时候可以提供它。这就是所谓的 “解锁” Swarm。

根据 Raft 故障容错一致性算法,Swarm 模式支持多个管理者。在这个场景中,无缝扩展了机密存储的安全性。每个管理者主机除了共享密钥之外,还有一个唯一的磁盘加密密钥。幸运的是,Raft 日志在磁盘上也是加密的,并且,在自动锁定模式下,没有 KEK 同样是不可访问的。

当一个节点被攻陷后发生了什么?

Docker Secrets

在传统的编排器中,挽回一台被攻陷的主机是一个缓慢而复杂的过程。使用 Swarm 模式,恢复它就像运行一个 Docker 节点的 rm 命令一样容易。这是从集群中删除一个受影响的节点,而 Docker 将去处理剩下的事情,即,重新均衡负载,并且确保其它的主机已经知道,而不会去与受影响的节点通讯。

正如我们看到的那样,感谢最小权限的编排器,甚至是,如果攻击者在主机上持续活动,它们将被从剩余的网络上切断。主机的证书 —— 它的身份标识 —— 被列入黑名单,因此,管理者也不能有效访问它。

结论

使用 Swarm 模式的 Docker 企业版,在缺省情况下确保了编排器的所有关键区域的安全:

  • 加入集群。阻止恶意节点加入到集群。
  • 把主机分组为安全区域。阻止攻击者的横向移动。
  • 安排任务。任务将仅被委派到允许的节点。
  • 分配资源。恶意节点不能 “盗取” 其它的负载或者资源。
  • 存储机密。从不明文保存并且从不写入到工人节点的磁盘上。
  • 与工人节点的通讯。使用相互认证的 TLS 加密。

因为 Swarm 模式的持续改进,Docker 团队正在努力将最小权限原则进一步推进。我们正在处理的一个任务是:如果一个管理者被攻陷了,怎么去保证剩下的节点的安全?路线图已经有了,其中一些功能已经可以使用,比如,白名单功能,仅允许特定的 Docker 镜像,阻止管理者随意运行负载。这是通过 Docker 可信内容来实现的。


via: https://blog.docker.com/2017/10/least-privilege-container-orchestration/

作者:Diogo Mónica 译者:qhwdw 校对:wxy

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

摘要

在 Linux 的日常使用中,我们经常需要修改一些配置文件,然而在软件升级以后,经常会面临配置更新后与原配置部分不兼容的问题(当然我们更多的可能是来制作软件升级的补丁)。在这种情况下我们通常有两种选择:

  • 对比现有配置,手动在新配置文件中改动
  • 利用 sedawk 等工具配合改动
  • 采用 diffpatch 制作增量补丁的方式改动

本文主要通过一个升级awesome 配置的例子,对第三种方法进行介绍和讲解。

diff 介绍

diff 是一个文件比较工具,可以逐行比较两个文件的不同,其中它有三种输出方式,分别是 normalcontext 以及 unified。区别如下:

  • normal 方式为默认输出方式,不需要加任何参数
  • context 相较于 normal 模式的简单输出,contetx 模式会输出修改过部分的上下文,默认是前后 3 行。使用参数 -c
  • unified 合并上下文模式则为新的上下文输出模式,同样为前后 3 行,只不过把上下文合并了显示了。使用参数 -u

:本文主要介绍 unified 模式

其他常用参数:

  • -r 递归处理目录
  • -N 将缺失的文件当作空白文件处理

diff 语法与文件格式

diff [options] old new

先来看一个简单的例子:

$ cat test1 
linux
linux
linux
linux
$ cat test2
locez
linux
locez
linux

此时输入 diff -urN test1 test2 会输出以下信息:

--- test1   2018-05-12 18:39:41.508375114 +0800
+++ test2   2018-05-12 18:41:00.124031736 +0800
@@ -1,4 +1,4 @@
+locez
 linux
-linux
-linux
+locez
 linux

先看前面 2 行,这两行为文件的基本信息,--- 开头为改变前的文件,+++ 开头为更新后的文件。

--- test1   2018-05-12 18:39:41.508375114 +0800
+++ test2   2018-05-12 18:41:00.124031736 +0800

第三行为上下文描述块,其中 -1,4 为旧文件的 4 行上下文,+1,4 为新文件的:

@@ -1,4 +1,4 @@

而具体到块里面的内容,前面有 - 号的则为删除,有 + 号为新增,不带符号则未做改变,仅仅是上下文输出。

patch 介绍

patch 是一个可以将 diff 生成的补丁应用到源文件,生成一个打过补丁版本的文件。语法:

patch [oiption] [originalfile [patchfile]]

常用参数:

  • -i 指定补丁文件
  • -pNumdiff 生成的补丁中,第一二行是文件信息,其中文件名是可以包含路径的,例如 --- /tmp/test1 2018-05-12 18:39:41.508375114 +0800 其中 -p0 代表完整的路径 /tmp/test1,而 -p1 则指 tmp/test1-pN 依此类推
  • -E 删除应用补丁后为空文件的文件
  • -o 输出到一个文件而不是直接覆盖文件

应用

awesome 桌面 3.5 与 4.0 之间的升级是不兼容的,所以在升级完 4.0 以后,awesome 桌面部分功能无法使用,因此需要迁移到新配置,接下来则应用 diffpatch 实现迁移,当然你也可以单纯使用 diff 找出不同,然后手动修改新配置。

现在有以下几个文件:

  • rc.lua.3.5 3.5 版本的默认配置文件,未修改
  • rc.lua.myconfig 基于 3.5 版本的个人配置文件
  • rc.lua.4.2 4.2 新默认配置,未修改

思路为利用 diff 提取出个人配置与 3.5 默认配置文件的增量补丁,然后把补丁应用在 4.2 的文件上实现迁移。

制作补丁

$ diff -urN rc.lua.3.5 rc.lua.myconfig  > mypatch.patch

应用补丁

$ patch rc.lua.4.2 -i mypatch.patch -o rc.lua
patching file rc.lua (read from rc.lua.4.2)
Hunk #1 FAILED at 38.
Hunk #2 FAILED at 55.
Hunk #3 succeeded at 101 with fuzz 1 (offset 5 lines).
Hunk #4 succeeded at 276 with fuzz 2 (offset 29 lines).
2 out of 4 hunks FAILED -- saving rejects to file rc.lua.rej

显然应用没有完全成功,其中在 38 行以及 55 行应用失败,并记录在 rc.lua.rej 里。

$ cat rc.lua.rej 
--- rc.lua.3.5  2018-05-12 19:15:54.922286085 +0800
+++ rc.lua.myconfig 2018-05-12 19:13:35.057911463 +0800
@@ -38,10 +38,10 @@

 -- {{{ Variable definitions
 -- Themes define colours, icons, font and wallpapers.
-beautiful.init("@AWESOME_THEMES_PATH@/default/theme.lua")
+beautiful.init("~/.config/awesome/default/theme.lua")

 -- This is used later as the default terminal and editor to run.
-terminal = "xterm"
+terminal = "xfce4-terminal"
 editor = os.getenv("EDITOR") or "nano"
 editor_cmd = terminal .. " -e " .. editor

@@ -55,18 +55,18 @@
 -- Table of layouts to cover with awful.layout.inc, order matters.
 local layouts =
 {
-    awful.layout.suit.floating,
-    awful.layout.suit.tile,
-    awful.layout.suit.tile.left,
-    awful.layout.suit.tile.bottom,
-    awful.layout.suit.tile.top,
+--    awful.layout.suit.floating,
+--    awful.layout.suit.tile,
+--    awful.layout.suit.tile.left,
+--    awful.layout.suit.tile.bottom,
+--    awful.layout.suit.tile.top,
     awful.layout.suit.fair,
     awful.layout.suit.fair.horizontal,
     awful.layout.suit.spiral,
     awful.layout.suit.spiral.dwindle,
     awful.layout.suit.max,
     awful.layout.suit.max.fullscreen,
-    awful.layout.suit.magnifier
+--    awful.layout.suit.magnifier
 }
 -- }}}

这里是主题,终端,以及常用布局的个人设置。

修正补丁

再次通过对比补丁文件与 4.2 文件,发现 38 行区块是要删除的东西不匹配,而 55 行区块则是上下文与要删除的内容均不匹配,导致不能应用补丁,于是手动修改补丁

$ vim mypatch.patch
--- rc.lua.3.5  2018-05-12 19:15:54.922286085 +0800
+++ rc.lua.myconfig 2018-05-12 19:13:35.057911463 +0800
@@ -38,10 +38,10 @@

 -- {{{ Variable definitions
 -- Themes define colours, icons, font and wallpapers.
-beautiful.init(gears.filesystem.get_themes_dir() .. "default/theme.lua")
+beautiful.init("~/.config/awesome/default/theme.lua")

 -- This is used later as the default terminal and editor to run.
-terminal = "xterm"
+terminal = "xfce4-terminal"
 editor = os.getenv("EDITOR") or "nano"
 editor_cmd = terminal .. " -e " .. editor

@@ -55,18 +55,18 @@

 -- Table of layouts to cover with awful.layout.inc, order matters.
 awful.layout.layouts = {
-    awful.layout.suit.floating,
-    awful.layout.suit.tile,
-    awful.layout.suit.tile.left,
-    awful.layout.suit.tile.bottom,
-    awful.layout.suit.tile.top,
+--    awful.layout.suit.floating,
+--    awful.layout.suit.tile,
+--    awful.layout.suit.tile.left,
+--    awful.layout.suit.tile.bottom,
+--    awful.layout.suit.tile.top,
     awful.layout.suit.fair,
     awful.layout.suit.fair.horizontal,
     awful.layout.suit.spiral,
     awful.layout.suit.spiral.dwindle,
     awful.layout.suit.max,
     awful.layout.suit.max.fullscreen,
-    awful.layout.suit.magnifier,
+--    awful.layout.suit.magnifier,
     awful.layout.suit.corner.nw,
     -- awful.layout.suit.corner.ne,
     -- awful.layout.suit.corner.sw,
....
....

输出省略显示,有兴趣的读者可以仔细与rc.lua.rej 文件对比,看看笔者是怎样改的。

再次应用补丁

$ patch rc.lua.4.2 -i mypatch.patch -o rc.lua
patching file rc.lua (read from rc.lua.4.2)
Hunk #1 succeeded at 41 (offset 3 lines).
Hunk #2 succeeded at 57 with fuzz 2 (offset 2 lines).
Hunk #3 succeeded at 101 with fuzz 1 (offset 5 lines).
Hunk #4 succeeded at 276 with fuzz 2 (offset 29 lines).
$ cp rc.lua ~/.config/awesome/rc.lua  ### 打完补丁直接使用

总结

diffpatch 配合使用,能当增量备份,而且还可以将补丁分发给他人使用,而且在日常的软件包打补丁也具有重要的意义,特别是内核补丁或者一些驱动补丁,打补丁遇到错误时候可以尝试自己修改,已满足自身特殊要求,修改的时候一定要抓住 2 个非常重要的要素:

  1. 要修改的内容是否匹配?特别是要删除的
  2. 上下文是否满足,特别是距离要修改的地方前后一行,以及上下文的行数是否满足,默认是 3 行上下文

当在笔记本电脑上录制声音时 —— 比如首次简单地录屏 —— 许多用户通常使用内置麦克风。但是,这些小型麦克风也会捕获很多背景噪音。在这个快速指南中,我们会学习如何使用 Fedora 中的 Audacity 快速移除音频文件中的背景噪音。

安装 Audacity

Audacity 是 Fedora 中用于混合、剪切和编辑音频文件的程序。在 Fedora 上它支持各种开箱即用的格式 - 包括 MP3 和 OGG。从软件中心安装 Audacity。

如果你更喜欢终端,请使用以下命令:

sudo dnf install audacity

导入您的音频、样本背景噪音

安装 Audacity 后,打开程序,使用 “File > Import” 菜单项导入你的声音。这个例子使用了一个来自 freesound.org 添加了噪音的声音

接下来,采样要滤除的背景噪音。导入音轨后,选择仅包含背景噪音的音轨区域。然后从菜单中选择 “Effect > Noise Reduction”,然后按下 “Get Noise Profile” 按钮。

过滤噪音

接下来,选择你要过滤噪音的音轨区域。通过使用鼠标进行选择,或者按 Ctrl + a 来选择整个音轨。最后,再次打开 “Effect > Noise Reduction” 对话框,然后单击确定以应用滤镜。

此外,调整设置,直到你的音轨听起来更好。这里是原始文件,接下来是用于比较的降噪音轨(使用默认设置):


via: https://fedoramagazine.org/audacity-quick-tip-quickly-remove-background-noise/

作者:Ryan Lerch 选题:lujun9972 译者:geekpi 校对:wxy

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

学习如何使用 Quagga 套件的路由协议去管理动态路由。

 title=

迄今为止,本系列文章中,我们已经在 Linux 局域网路由新手指南:第 1 部分 中学习了复杂的 IPv4 地址,在 Linux 局域网路由新手指南:第 2 部分 中学习了如何去手工创建静态路由。

今天,我们继续使用 Quagga 去管理动态路由,这是一个安装完后就不用理它的的软件。Quagga 是一个支持 OSPFv2、OSPFv3、RIP v1 和 v2、RIPng、以及 BGP-4 的路由协议套件,并全部由 zebra 守护程序管理。

OSPF 的意思是 最短路径优先 Open Shortest Path First 。OSPF 是一个内部网关协议(IGP);它可以用在局域网和跨因特网的局域网互联中。在你的网络中的每个 OSPF 路由器都包含整个网络的拓扑,并计算通过网络的最短路径。OSPF 会通过多播的方式自动对外传播它检测到的网络变化。你可以将你的网络分割为区域,以保持路由表的可管理性;每个区域的路由器只需要知道离开它的区域的下一跳接口地址,而不用记录你的网络的整个路由表。

RIP,即路由信息协议,是一个很老的协议,RIP 路由器向网络中周期性多播它的整个路由表,而不是像 OSPF 那样只多播网络的变化。RIP 通过跳数来测量路由,任何超过 15 跳的路由它均视为不可到达。RIP 设置很简单,但是 OSPF 在速度、效率以及弹性方面更佳。

BGP-4 是边界网关协议版本 4。这是用于因特网流量路由的外部网关协议(EGP)。你不会用到 BGP 协议的,除非你是因特网服务提供商。

准备使用 OSPF

在我们的小型 KVM 测试实验室中,用两台虚拟机表示两个不同的网络,然后将另一台虚拟机配置为路由器。创建两个网络:net1 是 192.168.110.0/24 ,而 net2 是 192.168.120.0/24。启用 DHCP 是明智的,否则你要分别进入这三个虚拟机,去为它们设置静态地址。Host 1 在 net1 中,Host 2 在 net2 中,而路由器同时与这两个网络连接。设置 Host 1 的网关地址为 192.168.110.126,Host 2 的网关地址为 192.168.120.136。

  • Host 1: 192.168.110.125
  • Host 2:192.168.120.135
  • Router:192.168.110.126 和 192.168.120.136

在路由器上安装 Quagga。在大多数 Linux 中它是 quagga 软件包。在 Debian 上还有一个单独的文档包 quagga-doc。取消 /etc/sysctl.conf 配置文件中如下这一行的注释去启用包转发功能:

net.ipv4.ip_forward=1

然后,运行 sysctl -p 命令让变化生效。

配置 Quagga

查看你的 Quagga 包中的示例配置文件,比如,/usr/share/doc/quagga/examples/ospfd.conf.sample。除非你的 Linux 版本按你的喜好做了创新,否则,一般情况下配置文件应该在 /etc/quagga 目录中。大多数 Linux 版本在这个目录下有两个文件,vtysh.confzebra.conf。它们提供了守护程序运行所需要的最小配置。除非你的发行版做了一些特殊的配置,否则,zebra 总是首先运行,当你启动 ospfd 的时候,它将自动启动。Debian/Ubuntu 是一个特例,稍后我们将会说到它。

每个路由器守护程序将读取它自己的配置文件,因此,我们必须创建 /etc/quagga/ospfd.conf,并输入如下内容:

!/etc/quagga/ospfd.conf
hostname router1
log file /var/log/quagga/ospfd.log
router ospf
  ospf router-id 192.168.110.15
  network 192.168.110.0/0 area 0.0.0.0
  network 192.168.120.0/0 area 0.0.0.0
access-list localhost permit 127.0.0.1/32
access-list localhost deny any
line vty
  access-class localhost

你可以使用感叹号(!)或者井号(#)去注释掉这些行。我们来快速浏览一下这些选项。

  • hostname 可以是你希望的任何内容。这里不是一般意义上的 Linux 主机名,但是,当你使用 vtysh 或者 telnet 登入时,你将看到它们。
  • log file 是你希望用于保存日志的任意文件。
  • router 指定路由协议。
  • ospf router-id 是任意的 32 位数字。使用路由器的一个 IP 地址就是很好的选择。
  • network 定义你的路由器要通告的网络。
  • access-list 限制 vtysh 登入,它是 Quagga 命令行 shell,它允许本地机器登入,并拒绝任何远程管理。

Debian/Ubuntu

在你启动守护程序之前,Debian/Ubuntu 相对其它的 Debian 衍生版可能多需要一步到多步。编辑 /etc/quagga/daemons ,除了 zebra=yesospfd=yes 外,使其它所有的行的值为 no

然后,在 Debian 上运行 ospfd 去启动 Quagga:

# systemctl start quagga

在大多数的其它 Linux 上,包括 Fedora 和 openSUSE,用如下命令启动 ospfd

# systemctl start ospfd

现在,Host 1 和 Host 2 将可以互相 ping 通对方和路由器。

这里用了许多篇幅去描述非常简单的设置。在现实中,路由器将连接两个交换机,然后为连接到这个交换机上的所有电脑提供一个网关。你也可以在你的路由器上添加更多的网络接口,这样你的路由器就可以为更多的网络提供路由服务,或者也可以直接连接到其它路由器上,或者连接到连接其它路由器的骨干网络上。

你或许不愿意如此麻烦地手工配置网络接口。最简单的方法是使用你的 DHCP 服务器去宣告你的路由器。如果你使用了 Dnsmasq,那么你就有了一个 DHCP 和 DNS 的一体化解决方案。

还有更多的配置选项,比如,加密的密码保护。更多内容请查看 Quagga 路由套件 的官方文档。


via: https://www.linux.com/learn/intro-to-linux/2018/3/dynamic-linux-routing-quagga

作者:CARLA SCHRODER 译者:qhwdw 校对:wxy

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

KVM(基于内核的虚拟机)是一款为类 Linux 系统提供的开源的全虚拟化解决方案,KVM 使用虚拟化扩展(如 Intel VTAMD-V)提供虚拟化功能。无论何时我们在任何 Linux 机器上安装 KVM,都会通过加载诸如 kvm-intel.ko(基于 Intel 的机器)和 kvm-amd.ko(基于 amd 的机器)的内核模块,使其成为 管理程序 hyervisor (LCTT 译注:一种监控和管理虚拟机运行的核心软件层)。

KVM 允许我们安装和运行多个虚拟机(Windows 和 Linux)。我们可以通过 virt-manager 的图形用户界面或使用 virt-installvirsh 命令在命令行界面来创建和管理基于 KVM 的虚拟机。

在本文中,我们将讨论如何在 Ubuntu 18.04 LTS 服务器上安装和配置 KVM 管理程序。我假设你已经在你的服务器上安装了 Ubuntu 18.04 LTS 。接下来登录到您的服务器执行以下步骤。

第一步:确认您的硬件是否支持虚拟化

执行 egrep 命令以验证您的服务器的硬件是否支持虚拟化,

linuxtechi@kvm-ubuntu18-04:~$ egrep -c '(vmx|svm)' /proc/cpuinfo
1

如果输出结果大于 0,就意味着您的硬件支持虚拟化。重启,进入 BIOS 设置中启用 VT 技术。

现在使用下面的命令安装 kvm-ok 实用程序,该程序用于确定您的服务器是否能够运行硬件加速的 KVM 虚拟机。

linuxtechi@kvm-ubuntu18-04:~$ sudo apt install cpu-checker

运行 kvm-ok 命令确认输出结果,

linuxtechi@kvm-ubuntu18-04:~$ sudo kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

第二步:安装 KVM 及其依赖包

运行下面的 apt 命令安装 KVM 及其依赖项:

linuxtechi@kvm-ubuntu18-04:~$ sudo apt update
linuxtechi@kvm-ubuntu18-04:~$ sudo apt install qemu qemu-kvm libvirt-bin  bridge-utils  virt-manager

只要上图相应的软件包安装成功,那么你的本地用户(对于我来说是 linuxtechi)将被自动添加到 libvirtd 群组。

第三步:启动并启用 libvirtd 服务

我们在 Ubuntu 18.04 服务器上安装 qemu 和 libvirtd 软件包之后,它就会自动启动并启用 libvirtd 服务,如果 libvirtd 服务没有开启,则运行以下命令开启,

linuxtechi@kvm-ubuntu18-04:~$ sudo service libvirtd start
linuxtechi@kvm-ubuntu18-04:~$ sudo update-rc.d libvirtd enable

现在使用下面的命令确认 libvirtd 服务的状态,

linuxtechi@kvm-ubuntu18-04:~$ service libvirtd status

输出结果如下所示:

第四步:为 KVM 虚拟机配置桥接网络

只有通过桥接网络,KVM 虚拟机才能访问外部的 KVM 管理程序或主机。在Ubuntu 18.04中,网络由 netplan 实用程序管理,每当我们新安装一个 Ubuntu 18.04 系统时,会自动创建一个名称为 /etc/netplan/50-cloud-init.yaml 文件,其配置了静态 IP 和桥接网络,netplan 实用工具将引用这个文件。

截至目前,我已经在此文件配置了静态 IP,文件的具体内容如下:

network:
  ethernets:
    ens33:
      addresses: [192.168.0.51/24]
      gateway4: 192.168.0.1
      nameservers:
        addresses: [192.168.0.1]
      dhcp4: no
      optional: true
  version: 2

我们在这个文件中添加桥接网络的配置信息,

linuxtechi@kvm-ubuntu18-04:~$ sudo vi /etc/netplan/50-cloud-init.yaml

network:
  version: 2
  ethernets:
    ens33:
      dhcp4: no
      dhcp6: no

  bridges:
    br0:
      interfaces: [ens33]
      dhcp4: no
      addresses: [192.168.0.51/24]
      gateway4: 192.168.0.1
      nameservers:
        addresses: [192.168.0.1]

正如你所看到的,我们已经从接口(ens33)中删除了 IP 地址,并将该 IP 添加到 br0 中,并且还将接口(ens33)添加到 br0。使用下面的 netplan 命令使更改生效,

linuxtechi@kvm-ubuntu18-04:~$ sudo netplan apply

如果您想查看 debug 日志请使用以下命令,

linuxtechi@kvm-ubuntu18-04:~$ sudo netplan --debug  apply

现在使用以下方法确认网络桥接状态:

linuxtechi@kvm-ubuntu18-04:~$ sudo networkctl status -a

linuxtechi@kvm-ubuntu18-04:~$ ifconfig

第五步:创建虚拟机(使用 virt-manager 或 virt-install 命令)

有两种方式创建虚拟机:

  • virt-manager(图形化工具)
  • virt-install(命令行工具)

使用 virt-manager 创建虚拟机

通过执行下面的命令启动 virt-manager

linuxtechi@kvm-ubuntu18-04:~$ sudo virt-manager

创建一个新的虚拟机:

点击“下一步”然后选择 ISO 镜像文件,我使用的是 RHEL 7.3 iso 镜像。

点击“下一步”。

在接下来的几个窗口中,系统会提示要求您为 VM 分配内存,处理器数量和磁盘空间。

并指定虚拟机名字和桥接网络名:

点击“结束”。

RHEL7-3-Installation-Virt-Manager

接下来只需要按照屏幕指示安装系统。

使用virt-install命令从命令行界面创建虚拟机

使用下面的 virt-install 命令从终端创建一个虚拟机,它将在命令行界面中开始安装,并根据您对虚拟机的名字,说明,ISO 文件位置和桥接配置的设置创建虚拟机。

linuxtechi@kvm-ubuntu18-04:~$ sudo virt-install  -n DB-Server  --description "Test VM for Database"  --os-type=Linux  --os-variant=rhel7  --ram=1096  --vcpus=1  --disk path=/var/lib/libvirt/images/dbserver.img,bus=virtio,size=10  --network bridge:br0 --graphics none  --location /home/linuxtechi/rhel-server-7.3-x86_64-dvd.iso --extra-args console=ttyS0

本文到此为止,我希望这篇文章能帮助你能够在 Ubuntu 18.04 服务器上成功安装 KVM。 除此之外,KVM 也是 Openstack 默认的管理程序。

阅读更多:“如何使用 virsh 命令创建,还原和删除 KVM 虚拟机快照”。


via: https://www.linuxtechi.com/install-configure-kvm-ubuntu-18-04-server/

作者:Pradeep Kumar 选题:lujun9972 译者:wyxplus 校对:wxy

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