2017年7月

或许你正在考虑(或正在进行)将机器人使用开源软件推向市场。这个机器人是基于 linux 构建的。也许你正在使用机器人操作系统(ROS)或任务导向操作套件(MOOS),或者是另外一个可以帮助你简化开发过程的开源中间件。当开发接近实用化,对回报的期望开始给你带来一些压力。你可能会被问到“我们的产品什么时候可以开始销售?”,这时你将面临重要的抉择。

你可以做下面两件事之一:

  1. 对现有的产品开始出货
  2. 回过头去,把产品化当做一个全新的问题来解决,并处理新的问题

不需要看很远,就可以找到采用方式(1)的例子。事实上,在物联网设备市场上,到处都是这样的设备。由于急于将设备推向市场,这些可以在设备中找到硬编码证书、开发密钥、各种安全漏洞和没有更新方式的产品并不少见。

想想 Mirai 僵尸网络,通过该僵尸网络发起的流量超过 1Tbps 的分布式拒绝服务攻击(DDos),导致一些互联网上最大的网站停止服务。这个僵尸网络主要由物联网设备组成。这种攻破设备的防御机制进而控制设备所开发的僵尸程序,是采用了超级酷的黑魔法在一个没有窗户的实验室(或地下基地)开发的吗?不是,默认(通常是硬编码)证书而已。这些设备的制造商是否快速反应并发布所有这些设备的更新,以确保设备的安全?不,很多制造商根本没有更新方法。他们召回设备而不是发布更新

不要急于将产品推向市场,而是退后一步。只要多思考几点,就可以使你自己和你所在公司避免痛苦。

例如,你的软件如何更新?必须能回答这个问题。你的软件不是完美的。只要几个星期你就会发现,当你在加利福尼亚使用自主的高机动性多用途轮式车辆(HMMWV)时,它把小灌木识别为一棵橡树。或者你不小心在软件中包含了你的 SSH 密钥。

基础操作系统如何更新?也许这仍然是你的产品的一部分,也是你回答上一个问题的答案。但也许你使用的操作系统来自于另外一个供应商。你如何从供应商那里得到更新并提供给客户?这就是安全漏洞真正让你头痛的地方:从来不更新的内核,或者严重过时的 openssl。

当你解决了更新问题,在更新过程出现问题时,机器人怎么恢复?我的示例是对前面问题的一个常见解决方案:自动安全更新。对于服务器和台式机以及显然是计算机的东西来说,这是一个很好的做法,因为大多数人意识到有一个可接受的方法来关闭它,而不是按住电源按钮 5 秒钟。机器人系统(以及大多数物联网系统)有一个问题,有时它们根本不被认为是计算机。如果您的机器人表现奇怪,有可能会被强制关闭。如果你的机器人行为奇怪是因为它正在快速安装一个内核更新,那么,现在你就有一个安装了半个内核的机器人镇纸了。你需要能够处理这种情况。

最后,你的工厂流程是什么?你如何安装 Linux,ROS(或者你使用的中间件),以及你要安装在设备上的你自己的东西?小的工厂可能会手工操作,但这种方法不成规模,也容易出错。其他厂商可能会制作一个定制化的初始发行版 ISO,但这是个不小的任务,在更新软件时也不容易维护。还有一些厂商会使用 Chef 或者有陡峭学习曲线的自动化工具,不久你就会意识到,你把大量的工程精力投入到了本来应该很简单的工作中。

所有这些问题都很重要。针对这些问题,如果你发现自己没有任何明确的答案,你应该加入我们的网络研讨会,在研讨会上我们讨论如何使用开放源代码构建一个商业化机器人。我们会帮助你思考这些问题,并可以回答你更多问题。


作者简介:

Kyle 是 Snapcraft 团队的一员,也是 Canonical 公司的常驻机器人专家,他专注于 snaps 和 snap 开发实践,以及 snaps 和 Ubuntu Core 的机器人技术实现。


via: https://insights.ubuntu.com/2017/07/18/things-to-consider-when-building-a-robot-with-open-source/

作者:Kyle Fazzari 译者:SunWave 校对:wxy

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

不久之前我看到了 RedMonk 的 Stephen O'Grady 发了一个关于开源协议的有趣的推特,那个推特里面有这张图。

 title=

这张图片显示了从 2010 到 2017 年间各种开源协议之间的使用率的变化。在这张图片里,显然 GPL 2.0 —— 最纯净的 copyleft 协议之一 —— 的使用率降低了一多半。该图表表明,开源项目中 MIT 协议和 Apache 协议开始受欢迎。GPL 3.0 的使用率也有所上涨。

这些意味着什么?

为什么 GPL 2.0 的使用率跌的这么多但是 GPL 3.0 仅仅是涨了一丁点?为什么 MIT 协议和 Apache 协议的使用率涨了那么多?

当然,有很多原因可以解释这件事情,但是我想这是因为商业开源项目的增多,以及商业社会对于 GPL 协议的担心导致的,我们细细掰扯。

GPL 协议与商业社会

我知道我要说的可能会激怒一些 GPL 粉,所以在你们开始喷之前,我想说明的是:我支持 GPL,我也是 GPL 粉丝。

我写过的所有软件都使用的是 GPL 协议,我也是一直是积极出资支持 自由软件基金会 以及 软件自由保护组织 以及他们的工作的,我支持使用 GPL 协议。我在这说的无关 GPL 的合法性或者 GPL 的巨大价值 —— 毫无疑问这是一个好协议 —— 我在这要说的是业内对于这个协议的看法。

大概四年之前,我参加了一个叫做 开源智库 Open Source Think Tank 的峰会。这个峰会是一个私人小型峰会,每年都会把各大开源企业的管理人员请到加利福尼亚的酒庄。这个峰会聚焦于建立关系、构建联盟,找到并解决行业问题。

在这个峰会上,有一个分组研究,在其中,与会者被分成小组,被要求给一个真实存在的核心的开源技术推荐一个开源协议。每个小组都给出了回应。不到十分之一的小组推荐了宽容许可证,没有人推荐 GPL 许可证。

我看到了开源行业对于 Apache 协议以及 MIT 协议的逐步认可,但是他们却对花时间理解、接受和熟悉 GPL 这件事高高挂起。

在这几年里,这种趋势仍在蔓延。除了 Black Duck 的调查之外, 2015 年 GitHub 上的开源协议调查 也显示 MIT 是人们的首选。我还能看到,在我工作的 XPRIZE (我们为我们的 Global Learning XPRIZE 选择了开源协议),在我作为社区领导顾问的工作方面,我也能感觉到那种倾向,因为越来越多的客户觉得把他们的代码用 GPL 发布不舒服。

随着 大约 65% 的公司对开源事业做贡献 ,自从 2010 年以后显然开源行业已经引来了不少商业兴趣和投资。我相信,我之前说的那些趋势,已经表明这行业不认为 GPL 适合搞开源生意。

连接社区和公司

说真的,GPL 的没落不太让人吃惊,因为有如下原因。

首先,开源行业已经转型升级,它要在社区发展以及……你懂的……真正能赚钱的商业模型中做出均衡,这是它们要做的最重要的决策。在开源思想发展之初,人们有种误解说,“如果你搞出来了,他们就会用”,他们确实会来使用你的软件,但是在很多情况下,都是“如果你搞出来了,他们不是一定要给你钱。”

随着历史的进程,我们看到了许多公司,比如 Red Hat、Automattic、Docker、Canonical、Digital Ocean 等等等等,探索着在开源领域中赚钱的法子。他们探索过分发模式、服务模式,核心开源模式等等。现在可以确定的是,传统的商业软件赚钱的方式已经不再适用开源软件;因此,你得选择一个能够支持你的公司的经营方式的开源协议。在赚钱和免费提供你的技术之间找到平衡在很多情况下是很困难的一件事。

这就是我们看到那些变化的原因。尽管 GPL 是一个开源协议,但是它根本上是个自由软件协议,作为自由软件协议,它的管理以及支持是由自由软件基金会提供的。

我喜欢自由软件基金会的作品,但是他们已经把观点局限于软件必须 100% 绝对自由。对于自由软件基金会没有多少可以妥协的余地,甚至很多出名的开源项目(比如很多 Linux 发行版)仅仅是因为一丁点二进制固件就被认为是 “非自由” 软件。

对于商业来说,最复杂的是它不是非黑即白的,更多的时候是两者混合的灰色,很少有公司有自由软件基金会(或者类似的组织,比如软件自由保护组织)的那种纯粹的理念,因此我想那些公司也不喜欢选择和那些理念相关的协议。

我需要说明,我不是在这是说自由软件基金会以及类似的组织(比如软件自由保护组织)的错。他们有着打造完全自由的软件的目标,对于他们来说,走它们选择的路十分合理。自由软件基金会以及软件自由保护组织做了了不起的工作,我将继续支持这些组织以及为他们工作的人们。我只是觉得这种对纯粹性的高要求的一个后果就是让那些公司认为自己难以达到要求,因此,他们使用了非 GPL 的其他协议。

我怀疑 GPL 的使用是随着开源软件增长而变化的。在以前,启动(开源)项目的根本原因之一是对开放性和软件自由的伦理因素的严格关注。GPL 无疑是项目的自然选择,Debian、Ubuntu、Fedora 和 Linux 内核以及很多都是例子。

近年来,尽管我们已经看到了不再那么挑剔的一代开发者的出现,但是如果我说的过激一些,他们缺少对于自由的关注。对于他们来说开源软件是构建软件的务实、实用的一部分,而无关伦理。我想,这就是为什么我们发现 MIT 和 Apache 协议的流行的原因。

未来 ?

这对于 GPL 意味着什么?

我的猜想是 GPL 依然将是一个主要选项,但是开发者将将之视为纯粹的自由软件协议。我想对于软件的纯粹性有高要求的项目会优先选择 GPL 协议。但是对于商业软件,为了保持我们之前讨论过的那种平衡,他们不会那么做。我猜测, MIT 以及 Apache 依然会继续流行下去。

不管怎样,好消息是开源/自由软件行业确实在增长。无论使用的协议会发生怎样的变化,技术确实变得更加开放,可以接触,人人都能使用。


作者简介:

Jono Bacon - Jono Bacon 是一位领袖级的社区管理者、演讲者、作者和播客主。他是 Jono Bacon 咨询公司的创始人,提供社区战略和执行、开发者流程和其它的服务。他之前任职于 GitHub、Canonical 和 XPRIZE、OpenAdvantage 的社区总监,并为大量的组织提供咨询和顾问服务。


via: https://opensource.com/article/17/2/decline-gpl

作者:Jono Bacon 译者:name1e5s 校对:wxy

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

让我们先看一下 kdump 的基本使用方法,和 kdump/kexec 在内核中是如何实现。

 title=

kdump 是获取崩溃的 Linux 内核转储的一种方法,但是想找到解释其使用和内部结构的文档可能有点困难。在本文中,我将研究 kdump 的基本使用方法,和 kdump/kexec 在内核中是如何实现。

kexec 是一个 Linux 内核到内核的引导加载程序,可以帮助从第一个内核的上下文引导到第二个内核。kexec 会关闭第一个内核,绕过 BIOS 或固件阶段,并跳转到第二个内核。因此,在没有 BIOS 阶段的情况下,重新启动变得更快。

kdump 可以与 kexec 应用程序一起使用 —— 例如,当第一个内核崩溃时第二个内核启动,第二个内核用于复制第一个内核的内存转储,可以使用 gdbcrash 等工具分析崩溃的原因。(在本文中,我将使用术语“第一内核”作为当前运行的内核,“第二内核” 作为使用 kexec 运行的内核,“捕获内核” 表示在当前内核崩溃时运行的内核。)

kexec 机制在内核以及用户空间中都有组件。内核提供了几个用于 kexec 重启功能的系统调用。名为 kexec-tools 的用户空间工具使用这些调用,并提供可执行文件来加载和引导“第二内核”。有的发行版还会在 kexec-tools 上添加封装器,这有助于捕获并保存各种转储目标配置的转储。在本文中,我将使用名为 distro-kexec-tools 的工具来避免上游 kexec 工具和特定于发行版的 kexec-tools 代码之间的混淆。我的例子将使用 Fedora Linux 发行版。

Fedora kexec-tools 工具

使用 dnf install kexec-tools 命令在 Fedora 机器上安装 fedora-kexec-tools。在安装 fedora-kexec-tools 后可以执行 systemctl start kdump 命令来启动 kdump 服务。当此服务启动时,它将创建一个根文件系统(initramfs),其中包含了要挂载到目标位置的资源,以保存 vmcore,以及用来复制和转储 vmcore 到目标位置的命令。然后,该服务将内核和 initramfs 加载到崩溃内核区域内的合适位置,以便在内核崩溃时可以执行它们。

Fedora 封装器提供了两个用户配置文件:

  1. /etc/kdump.conf 指定修改后需要重建 initramfs 的配置参数。例如,如果将转储目标从本地磁盘更改为 NFS 挂载的磁盘,则需要由“捕获内核”所加载的 NFS 相关的内核模块。
  2. /etc/sysconfig/kdump 指定修改后不需要重新构建 initramfs 的配置参数。例如,如果只需修改传递给“捕获内核”的命令行参数,则不需要重新构建 initramfs。

如果内核在 kdump 服务启动之后出现故障,那么“捕获内核”就会执行,其将进一步执行 initramfs 中的 vmcore 保存过程,然后重新启动到稳定的内核。

kexec-tools 工具

编译 kexec-tools 的源代码得到了一个名为 kexec 的可执行文件。这个同名的可执行文件可用于加载和执行“第二内核”,或加载“捕获内核”,它可以在内核崩溃时执行。

加载“第二内核”的命令:

# kexec -l kernel.img --initrd=initramfs-image.img –reuse-cmdline

--reuse-command 参数表示使用与“第一内核”相同的命令行。使用 --initrd 传递 initramfs。 -l 表明你正在加载“第二内核”,其可以由 kexec 应用程序本身执行(kexec -e)。使用 -l 加载的内核不能在内核崩溃时执行。为了加载可以在内核崩溃时执行的“捕获内核”,必须传递参数 -p 取代 -l

加载捕获内核的命令:

# kexec -p kernel.img --initrd=initramfs-image.img –reuse-cmdline

echo c > /pros/sysrq-trigger 可用于使内核崩溃以进行测试。有关 kexec-tools 提供的选项的详细信息,请参阅 man kexec。在转到下一个部分之前,请看这个 kexec\_dump 的演示:

kdump: 端到端流

下图展示了流程图。必须在引导“第一内核”期间为捕获内核保留 crashkernel 的内存。您可以在内核命令行中传递 crashkernel=Y@X,其中 @X 是可选的。crashkernel=256M 适用于大多数 x86\_64 系统;然而,为崩溃内核选择适当的内存取决于许多因素,如内核大小和 initramfs,以及 initramfs 中包含的模块和应用程序运行时的内存需求。有关传递崩溃内核参数的更多方法,请参阅 kernel-parameters 文档

pratyush_f1.png

您可以将内核和 initramfs 镜像传递给 kexec 可执行文件,如(kexec-tools)部分的命令所示。“捕获内核”可以与“第一内核”相同,也可以不同。通常,一样即可。Initramfs 是可选的;例如,当内核使用 CONFIG_INITRAMFS_SOURCE 编译时,您不需要它。通常,从第一个 initramfs 中保存一个不一样的捕获 initramfs,因为在捕获 initramfs 中自动执行 vmcore 的副本能获得更好的效果。当执行 kexec 时,它还加载了 elfcorehdr 数据和 purgatory 可执行文件(LCTT 译注:purgatory 就是一个引导加载程序,是为 kdump 定作的。它被赋予了“炼狱”这样一个古怪的名字应该只是一种调侃)。 elfcorehdr 具有关于系统内存组织的信息,而 purgatory 可以在“捕获内核”执行之前执行并验证第二阶段的二进制或数据是否具有正确的 SHA。purgatory 也是可选的。

当“第一内核”崩溃时,它执行必要的退出过程并切换到 purgatory(如果存在)。purgatory 验证加载二进制文件的 SHA256,如果是正确的,则将控制权传递给“捕获内核”。“捕获内核”根据从 elfcorehdr 接收到的系统内存信息创建 vmcore。因此,“捕获内核”启动后,您将看到 /proc/vmcore 中“第一内核”的转储。根据您使用的 initramfs,您现在可以分析转储,将其复制到任何磁盘,也可以是自动复制的,然后重新启动到稳定的内核。

内核系统调用

内核提供了两个系统调用:kexec_load()kexec_file_load(),可以用于在执行 kexec -l 时加载“第二内核”。它还为 reboot() 系统调用提供了一个额外的标志,可用于使用 kexec -e 引导到“第二内核”。

kexec_load()kexec_load() 系统调用加载一个可以在之后通过 reboot() 执行的新的内核。其原型定义如下:

long kexec_load(unsigned long entry, unsigned long nr_segments,
struct kexec_segment *segments, unsigned long flags);

用户空间需要为不同的组件传递不同的段,如内核,initramfs 等。因此,kexec 可执行文件有助于准备这些段。kexec_segment 的结构如下所示:

struct kexec_segment {
    void *buf;
    /* 用户空间缓冲区 */
    size_t bufsz;
    /* 用户空间中的缓冲区长度 */
    void *mem;
    /* 内核的物理地址 */
    size_t memsz;
    /* 物理地址长度 */
};

当使用 LINUX_REBOOT_CMD_KEXEC 调用 reboot() 时,它会引导进入由 kexec_load 加载的内核。如果标志 KEXEC_ON_CRASH 被传递给 kexec_load(),则加载的内核将不会使用 reboot(LINUX_REBOOT_CMD_KEXEC) 来启动;相反,这将在内核崩溃中执行。必须定义 CONFIG_KEXEC 才能使用 kexec,并且为 kdump 定义 CONFIG_CRASH_DUMP

kexec_file_load():作为用户,你只需传递两个参数(即 kernelinitramfs)到 kexec 可执行文件。然后,kexec 从 sysfs 或其他内核信息源中读取数据,并创建所有段。所以使用 kexec_file_load() 可以简化用户空间,只传递内核和 initramfs 的文件描述符。其余部分由内核本身完成。使用此系统调用时应该启用 CONFIG_KEXEC_FILE。它的原型如下:

long kexec_file_load(int kernel_fd, int initrd_fd, unsigned long
cmdline_len, const char __user * cmdline_ptr, unsigned long
flags);

请注意,kexec_file_load 也可以接受命令行,而 kexec_load() 不行。内核根据不同的系统架构来接受和执行命令行。因此,在 kexec_load() 的情况下,kexec-tools 将通过其中一个段(如在 dtb 或 ELF 引导注释等)中传递命令行。

目前,kexec_file_load() 仅支持 x86 和 PowerPC。

当内核崩溃时会发生什么

当第一个内核崩溃时,在控制权传递给 purgatory 或“捕获内核”之前,会执行以下操作:

  • 准备 CPU 寄存器(参见内核代码中的 crash_setup_regs());
  • 更新 vmcoreinfo 备注(请参阅 crash_save_vmcoreinfo());
  • 关闭非崩溃的 CPU 并保存准备好的寄存器(请参阅 machine_crash_shutdown()crash_save_cpu());
  • 您可能需要在此处禁用中断控制器;
  • 最后,它执行 kexec 重新启动(请参阅 machine_kexec()),它将加载或刷新 kexec 段到内存,并将控制权传递给进入段的执行文件。输入段可以是下一个内核的 purgatory 或开始地址。

ELF 程序头

kdump 中涉及的大多数转储核心都是 ELF 格式。因此,理解 ELF 程序头部很重要,特别是当您想要找到 vmcore 准备的问题。每个 ELF 文件都有一个程序头:

  • 由系统加载器读取,
  • 描述如何将程序加载到内存中,
  • 可以使用 Objdump -p elf_file 来查看程序头。

vmcore 的 ELF 程序头的示例如下:

# objdump -p vmcore
vmcore:
file format elf64-littleaarch64
Program Header:
NOTE off 0x0000000000010000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**0 filesz
0x00000000000013e8 memsz 0x00000000000013e8 flags ---
LOAD off 0x0000000000020000 vaddr 0xffff000008080000 paddr 0x0000004000280000 align 2**0 filesz
0x0000000001460000 memsz 0x0000000001460000 flags rwx
LOAD off 0x0000000001480000 vaddr 0xffff800000200000 paddr 0x0000004000200000 align 2**0 filesz
0x000000007fc00000 memsz 0x000000007fc00000 flags rwx
LOAD off 0x0000000081080000 vaddr 0xffff8000ffe00000 paddr 0x00000040ffe00000 align 2**0 filesz
0x00000002fa7a0000 memsz 0x00000002fa7a0000 flags rwx
LOAD off 0x000000037b820000 vaddr 0xffff8003fa9e0000 paddr 0x00000043fa9e0000 align 2**0 filesz
0x0000000004fc0000 memsz 0x0000000004fc0000 flags rwx
LOAD off 0x00000003807e0000 vaddr 0xffff8003ff9b0000 paddr 0x00000043ff9b0000 align 2**0 filesz
0x0000000000010000 memsz 0x0000000000010000 flags rwx
LOAD off 0x00000003807f0000 vaddr 0xffff8003ff9f0000 paddr 0x00000043ff9f0000 align 2**0 filesz
0x0000000000610000 memsz 0x0000000000610000 flags rwx

在这个例子中,有一个 note 段,其余的是 load 段。note 段提供了有关 CPU 信息,load 段提供了关于复制的系统内存组件的信息。

vmcore 从 elfcorehdr 开始,它具有与 ELF 程序头相同的结构。参见下图中 elfcorehdr 的表示:

pratyush_f2.png

kexec-tools 读取 /sys/devices/system/cpu/cpu%d/crash_notes 并准备 CPU PT_NOTE 的标头。同样,它读取 /sys/kernel/vmcoreinfo 并准备 vmcoreinfo PT_NOTE 的标头,从 /proc/iomem 读取系统内存并准备存储器 PT_LOAD 标头。当“捕获内核”接收到 elfcorehdr 时,它从标头中提到的地址中读取数据,并准备 vmcore。

Crash note

Crash notes 是每个 CPU 中用于在系统崩溃的情况下存储 CPU 状态的区域;它有关于当前 PID 和 CPU 寄存器的信息。

vmcoreinfo

该 note 段具有各种内核调试信息,如结构体大小、符号值、页面大小等。这些值由捕获内核解析并嵌入到 /proc/vmcore 中。 vmcoreinfo 主要由 makedumpfile 应用程序使用。在 Linux 内核,include/linux/kexec.h 宏定义了一个新的 vmcoreinfo。 一些示例宏如下所示:

  • VMCOREINFO_PAGESIZE()
  • VMCOREINFO_SYMBOL()
  • VMCOREINFO_SIZE()
  • VMCOREINFO_STRUCT_SIZE()

makedumpfile

vmcore 中的许多信息(如可用页面)都没有用处。makedumpfile 是一个用于排除不必要的页面的应用程序,如:

  • 填满零的页面;
  • 没有私有标志的缓存页面(非专用缓存);
  • 具有私有标志的缓存页面(专用缓存);
  • 用户进程数据页;
  • 可用页面。

此外,makedumpfile 在复制时压缩 /proc/vmcore 的数据。它也可以从转储中删除敏感的符号信息; 然而,为了做到这一点,它首先需要内核的调试信息。该调试信息来自 VMLINUXvmcoreinfo,其输出可以是 ELF 格式或 kdump 压缩格式。

典型用法:

# makedumpfile -l --message-level 1 -d 31 /proc/vmcore makedumpfilecore

详细信息请参阅 man makedumpfile

kdump 调试

新手在使用 kdump 时可能会遇到的问题:

kexec -p kernel_image 没有成功

  • 检查是否分配了崩溃内存。
  • cat /sys/kernel/kexec_crash_size 不应该有零值。
  • cat /proc/iomem | grep "Crash kernel" 应该有一个分配的范围。
  • 如果未分配,则在命令行中传递正确的 crashkernel= 参数。
  • 如果没有显示,则在 kexec 命令中传递参数 -d,并将输出信息发送到 kexec-tools 邮件列表。

在“第一内核”的最后一个消息之后,在控制台上看不到任何东西(比如“bye”)

  • 检查 kexec -e 之后的 kexec -l kernel_image 命令是否工作。
  • 可能缺少支持的体系结构或特定机器的选项。
  • 可能是 purgatory 的 SHA 验证失败。如果您的体系结构不支持 purgatory 中的控制台,则很难进行调试。
  • 可能是“第二内核”早已崩溃。
  • 将您的系统的 earlyconearlyprintk 选项传递给“第二内核”的命令行。
  • 使用 kexec-tools 邮件列表共享第一个内核和捕获内核的 dmesg 日志。

资源

fedora-kexec-tools

  • GitHub 仓库:git://pkgs.fedoraproject.org/kexec-tools
  • 邮件列表:[email protected]
  • 说明:Specs 文件和脚本提供了用户友好的命令和服务,以便 kexec-tools 可以在不同的用户场景下实现自动化。

kexec-tools

  • GitHub 仓库:git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
  • 邮件列表:[email protected]
  • 说明:使用内核系统调用并提供用户命令 kexec

Linux kernel

  • GitHub 仓库: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  • 邮件列表:[email protected]
  • 说明:实现了 kexec_load()kexec_file_load()reboot() 系统调用和特定体系结构的代码,例如 machine_kexec()machine_crash_shutdown()

Makedumpfile

  • GitHub 仓库: git://git.code.sf.net/p/makedumpfile/code
  • 邮件列表:[email protected]
  • 说明:从转储文件中压缩和过滤不必要的组件。

(题图:PenguinBoot,修改:Opensource.com. CC BY-SA 4.0


作者简介:

Pratyush Anand - Pratyush 正在以以为 Linux 内核专家的身份与 Red Hat 合作。他主要负责 Red Hat 产品和上游所面临的几个 kexec/kdump 问题。他还处理 Red Hat 支持的 ARM64 平台周围的其他内核调试、跟踪和性能问题。除了 Linux 内核,他还在上游的 kexec-tools 和 makedumpfile 项目中做出了贡献。他是一名开源爱好者,并在教育机构举办志愿者讲座,促进了 FOSS。


via: https://opensource.com/article/17/6/kdump-usage-and-internals

作者:Pratyush Anand 译者:firmianay 校对:wxy

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

 title=

简介:Bro 网络分析框架

Bro 是一个开源的网络分析框架,侧重于网络安全监控。这是一项长达 15 年的研究成果,被各大学、研究实验室、超级计算机中心和许多开放科学界广泛使用。它主要由伯克利国际计算机科学研究所和伊利诺伊大学厄巴纳-香槟分校的国家超级计算机应用中心开发。

Bro 的功能包括:

  • Bro 的脚本语言支持针对站点定制监控策略
  • 针对高性能网络
  • 分析器支持许多协议,可以在应用层面实现高级语义分析
  • 它保留了其所监控的网络的丰富的应用层统计信息
  • Bro 能够与其他应用程序接口实时地交换信息
  • 它的日志全面地记录了一切信息,并提供网络活动的高级存档

本教程将介绍如何从源代码构建,并在 Ubuntu 16.04 服务器上安装 Bro。

准备工作

Bro 有许多依赖文件:

从源代码构建还需要:

  • CMake 2.8+
  • Make
  • GCC 4.8+ or Clang 3.3+
  • SWIG
  • GNU Bison
  • Flex
  • Libpcap headers
  • OpenSSL headers
  • zlib headers

起步

首先,通过执行以下命令来安装所有必需的依赖项:

# apt-get install cmake make gcc g++ flex bison libpcap-dev libssl-dev python-dev swig zlib1g-dev

安装定位 IP 地理位置的 GeoIP 数据库

Bro 使用 GeoIP 的定位地理位置。安装 IPv4 和 IPv6 版本:

$ wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
$wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCityv6-beta/GeoLiteCityv6.dat.gz

解压这两个压缩包:

$ gzip -d GeoLiteCity.dat.gz
$ gzip -d GeoLiteCityv6.dat.gz

将解压后的文件移动到 /usr/share/GeoIP 目录下:

# mvGeoLiteCity.dat /usr/share/GeoIP/GeoIPCity.dat
# mv GeoLiteCityv6.dat /usr/share/GeoIP/GeoIPCityv6.dat

现在,可以从源代码构建 Bro 了。

构建 Bro

最新的 Bro 开发版本可以通过 git 仓库获得。执行以下命令:

$ git clone --recursive git://git.bro.org/bro

转到克隆下来的目录,然后使用以下命令就可以简单地构建 Bro:

$ cd bro
$ ./configure
$ make

make 命令需要一些时间来构建一切。确切的时间取决于服务器的性能。

可以使用一些参数来执行 configure 脚本,以指定要构建的依赖关系,特别是 --with-* 选项。

安装 Bro

在克隆的 bro 目录中执行:

# make install

默认安装路径为 /usr/local/bro

配置 Bro

Bro 的配置文件位于 /usr/local/bro/etc 目录下。 这里有三个文件:

  • node.cfg,用于配置要监视的单个节点(或多个节点)。
  • broctl.cfg,BroControl 的配置文件。
  • networks.cgf,包含一个使用 CIDR 标记法表示的网络列表。

配置邮件设置

打开 broctl.cfg 配置文件:

# $EDITOR /usr/local/bro/etc/broctl.cfg

查看 Mail Options 选项,并编辑 MailTo 行如下:

# Recipient address for emails sent out by Bro and BroControl
MailTo = [email protected]

保存并关闭。还有许多其他选项,但在大多数情况下,默认值就足够好了。

选择要监视的节点

开箱即用,Bro 被配置为以独立模式运行。在本教程中,我们就是做一个独立的安装,所以没有必要改变。但是,也请查看 node.cfg 配置文件:

# $EDITOR /usr/local/bro/etc/node.cfg

[bro] 部分,你应该看到这样的东西:

[bro]
type=standalone
host=localhost
interface=eth0

请确保 inferface 与 Ubuntu 16.04 服务器的公网接口相匹配。

保存并退出。

配置监视节点的网络

最后一个要编辑的文件是 network.cfg。使用文本编辑器打开它:

# $EDITOR /usr/local/bro/etc/networks.cfg

默认情况下,你应该看到以下内容:

# List of local networks in CIDR notation, optionally followed by a
# descriptive tag.
# For example, "10.0.0.0/8" or "fe80::/64" are valid prefixes.

10.0.0.0/8          Private IP space
172.16.0.0/12       Private IP space
192.168.0.0/16      Private IP space

删除这三个条目(这只是如何使用此文件的示例),并输入服务器的公用和专用 IP 空间,格式如下:

X.X.X.X/X        Public IP space
X.X.X.X/X        Private IP space

保存并退出。

使用 BroControl 管理 Bro 的安装

管理 Bro 需要使用 BroControl,它支持交互式 shell 和命令行工具两种形式。启动该 shell:

# /usr/local/bro/bin/broctl

要想使用命令行工具,只需将参数传递给上一个命令,例如:

# /usr/local/bro/bin/broctl status

这将通过显示以下的输出来检查 Bro 的状态:

Name         Type       Host          Status    Pid    Started
bro          standalone localhost     running   6807   20 Jul 12:30:50

结论

这是一篇 Bro 的安装教程。我们使用基于源代码的安装,因为它是获得可用的最新版本的最有效的方法,但是该网络分析框架也可以下载预构建的二进制格式文件。

下次见!


via: https://www.unixmen.com/how-to-install-bro-ubuntu-1604/

作者:Giuseppe Molica 译者:firmianay 校对:wxy

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

在 2016 年 7 月,Facebook 公司的 React.js 开源许可协议曾引起激烈争论。一年过后,该协议再次成为开源社区的头条新闻。

背景介绍

React.js 是 Facebook 推出的一个用来构建用户界面的 JavaScript 库,起源于 Facebook 的内部项目,用来架设 Instagram 的网站。

  • 2013 年 5 月,Facebook 将 React.js 开源
  • 2016 年 7月,React.js 开源许可协议中的附加专利条款引发争议。
  • 2016 年 11 月,Facebook 发布官方问答,对附加专利条款进行澄清。
  • 2017 年 7 月,Apache 基金会禁止使用遵循 BSD 许可证 + 专利开源协议的 JAR 包。

Apache 基金会的立场

2017 年 7 月,针对 Facebook 公司的 BSD 许可证 + 专利开源协议,Apache 基金会提出了如下建议:

  1. 任何新项目、子项目或代码库都不允许使用遵循 Facebook 公司 “BSD 许可证 + 专利开源协议”的 jar 包。换句话说,如果你之前没有使用过,之后也不允许去使用。这种许可协议被 Apache 基金会列为 X 类别(Cat-X)。
  2. 如果你一直在使用,并且在 release 中已经这么做了,那么在 2017 年 8 月 31 日之前,你将暂时从 X 类别中被排除。在此之后,任何和所有使用 Facebook 公司 “BSD 许可证+专利开源协议”的产品都将被 Apache 基金会禁止使用,你必须找到采用了合适许可证的替代品,或者放弃使用。这种情况没有例外。
  3. 上述条款没有涵盖的任何其他情形也禁止使用。

X 类别被定义为“Apache 产品中可能不允许的许可证”,目前包括 GNU GPL、GNU LGPL、BCL、BSD-4-Clause 等许可证。有关禁用许可证列表可以在 Apache 基金会网站上查询

Facebook 的 “BSD 许可证 + 专利开源协议”

React 是一种流行的用于创建丰富用户界面的 JavaScript 技术,最初来源于 Facebook,并被广泛使用。该技术依据 BSD 许可证进行开源,但是,它的附加专利条款需要特别注意(以下为节选)。

Facebook, Inc.(Facebook)特此授予软件的每个接收人(“你”)基于任何 “必要权利要求” Necessary Claims 的永久的、全球范围的、免版税的、非排他的、不可撤销的许可(遵守以下终止条款),可以制造、曾经制造、使用、销售、许诺销售、进口以及转移软件。

如果您(或任何您的子公司、关联方或代理商)直接或间接地启动了专利主张,或从专利主张中直接获取经济利益,本协议授予的许可将自动终止,恕不另行通知:(i)针对 Facebook 或其任何子公司或关联方;(ii)全部或部分来自于 Facebook 或其任何子公司或关联方的任何软件、技术、产品或服务的专利主张针对任何一方;或(iii)与软件相关的任何一方。尽管如此,如果 Facebook 或其任何子公司或关联方首先对你提起专利侵权诉讼指控,你在该诉讼中针对与软件无关的一方提起专利侵权反诉,你所被授予的许可不会因反诉而在本段第(i)款的规定下终止。

如果你的项目中正在使用或打算使用 React,你可能需要去咨询律师了。由于专利条款的限制,你不能做任何构成与 Facebook 竞争的事情。如果你采取法律行动或者以其他方式挑战 Facebook,那么你使用 React 的许可会被立即撤销。

如果你与其他使用 React 的公司发生法律纠纷,那你使用 React 的许可也会被撤销。Aurelia 框架创建者、Angular 2 开发团队前成员 Rob Eisenberg 表示,这就是 Google 公司和 Microsoft 公司的员工在工作中不允许使用 React.js 的原因。

虽然这只是在理论上对大多数采用 React 的项目可能产生的影响,但仍然值得特别注意,并且,类似 WordPress Calypso 这种已经与 React.js 建立了深刻联系的项目,可能会受到限制。运营 WordPress 的 Automattic 公司对一些小官司并不陌生,但这次很可能成为 Facebook 这个大公司的诉讼对象。

Drupal 和 WordPress 等许多开源产品都在采用 Facebook 公司的 React.js 技术。对于 Automattic 公司这种拥有开源产品的公司来说,未来如果被 Facebook 认定与 Facebook 构成竞争,将会是一个棘手的问题。

目前 Facebook 正如日中天,以上可能性发生的几率比较小,但如同 Yahoo 公司一样,Facebook 总有一天会从神坛跌落。到那时,Facebook 公司很有可能会从竞争角度充分利用许可协议所赋予的权利。所以,如果你打算利用 React.js 创建一个有可能终结 Facebook 神话的产品,最好先咨询你的律师。

但是,美国专利法非常复杂,尤其是在知识产权相关问题上,往往难以解释。从 Google 和 Oracle 公司有关安卓使用 Java 的争议可以看出,解决此类问题往往需要好几年时间。这意味着你必须要财大气粗,即使是你最后赢了官司。

Facebook 公司的官方问答

React 的技术优势难以挑战。从开发者构建 web 用户界面方面来说,React 引发了一场变革。Facebook 在某些方面不太清楚的许可协议(BSD 许可证+专利)在开源开发者中间引发了激烈争论。开源社区继续坚持对“邪恶公司”的抵制,而 Facebook 很容易被归为此类公司。

2016 年 11 月,Facebook 澄清了其在 React、React Native 和其他许多项目中广泛采用的开源许可协议方面的立场。与任何法律文本一样,软件许可协议非常难以解释。Facebook 提供了一个 FAQ 来回应经常被问到的问题。其中包括:

  1. 如果我创建了一个竞争性产品,那么 Facebook 公司 “BSD 许可证+专利许可协议”中的附加专利授权是否会被终止?
  2. 如果我用专利侵权以外的理由起诉 Facebook,那么 Facebook 公司 “BSD许可证+专利许可协议”中的附加专利授权是否会被终止?
  3. 如果 Facebook 公司首先起诉我专利侵权,而我反诉 Facebook 公司专利侵权,那么 Facebook 公司 “BSD许可证+专利许可协议”中的附加专利授权是否会被终止?
  4. Facebook 公司 “BSD 许可证+专利许可协议”中的附加专利授权的终止是否也会导致版权许可的终止?

对 1、2、4 的回答是明确的“”,而对于第 3 个问题,FAQ 中规定,反诉主张不得与 Facebook 任何专利相关。上述官方说法比较可靠,在这个 Facebook 即便成为专利流氓也所获甚微的时刻,Facebook 仍然坚持其对 React 许可协议的看法。

使用 React.js 的开发者怎么办?

Apple 和 Microsoft 等行业巨头对于采用 React 的态度令人关注。有报道称,由于担心法律纠纷,这些巨头们已经禁止在项目中使用 React UI 库。但显然这是一个引发争议的问题,因为两家巨头都发布了使用 React 的网络资源或库。

Microsoft 提供了一个用于扩展 PowerPoint 和其他 Office365 产品的 React UI 组件库。Apple 开发者网站上的 API 文档采用 React.js 构建。

以上两款产品都不是两家公司的核心产品,Apple 也不太可能发布一款利用 React Native 编写的 iOS 邮件客户端。值得注意的是,虽然两家公司都看到了利用 React 创建 web 用户界面的价值,但它们的法律部门也没有因此遇到麻烦。

所以对大多数应用案例来说,似乎专利诉讼被严格限制在使用中的具体工具上,在这种情况下无需过分担心。由于使用了宽松的 BSD 许可证,对于开发者来说,React 实际上比使用传染性的 GPL 许可证的库更为安全。

Facebook 公司的数据库引擎 RocksDB 正准备将许可证更改为 Apache 2.0。但 React.js 是一个特殊的项目,Facebook 公司似乎有意继续保留专利条款。

虽然商业实体很乐意在产品中使用 React 授权代码,尽管 WordPress 等许多受欢迎的开源项目仍将继续采用 React,但开源社区对 Facebook 不断捍卫和澄清这种特殊授权感到了厌倦。

因此,如果你想找到类似 Solr 这种采用 React UI 的 Apache 项目,可能还需要很长时间。幸运的是,React 本身并非独一无二,你的项目可以采用与 React 类似的替代品,例如 PreactInferno,而不用担心遇到 React 的专利授权问题。

参考来源

(题图:facebook.github.io)


编译:

薛亮,北京集慧智佳知识产权管理咨询股份有限公司互联网事业部 高级咨询师,擅长专利检索,专利分析,竞争对手跟踪,FTO分析,开源软件知识产权风险分析,致力于为互联网企业,高科技公司提供知识产权咨询服务。

欢迎来到 Linux 天气预报

本页面是为了跟踪在不久的将来某个时间内有可能出现在主线内核和/或主要发行版中的 Linux 开发社区的进展情况。你的“首席气象学家”是 LWN.net 执行主编 Jonathan Corbet。如果你有改进预测的建议(特别是如果你有一个你认为应该跟踪的项目或修补程序的情况下),请在下面补充你的意见。

预测摘要

当前情况:内核 4.12 于 7 月 2 日发布。它包含了许多新功能,包括:

  • BFQ 和 Kyber 块 I/O 调度器。已经开发多年的 BFQ 在交互式系统上表现更好,这引起了移动设备领域的兴趣。相反,Kyber 是一个更简单的调度程序,旨在用于通常出现在企业配置中的快速设备。
  • epoll\_wait() 系统调用现在可以执行网络套接字的繁忙轮询。
  • 实时修补机制已经实现了混合一致性模型,这将可以把更复杂的补丁应用于运行中的内核。
  • 可信执行框架应该使得内核与在 ARM TrustZone 安全世界中运行的代码之间的交互更加容易。

4.12 是最繁忙的内核开发周期之一,合并了近 15000 次更新。有关这些变化来源的概述,请参阅这里

短期预测:4.13 内核预期在 2017 年 9 月初发布。这个内核中会出现的一些变化是:

4.13 内核现在处于稳定时期,所以在这个开发周期的剩余时间内只会接受修复补丁。

这篇文章根据知识共享署名 - 共享 3.0 许可证获得许可。


via: https://www.linux.com/news/2017/7/linux-weather-forecast

作者:JONATHAN CORBET 译者:geekpi 校对:wxy

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