mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-13 22:30:37 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
wxy
commit
ebe1f37ca4
@ -1,56 +1,79 @@
|
||||
如何在 CentOS 7 / RHEL 7 终端服务器上安装 KVM
|
||||
======
|
||||
|
||||
如何在 CnetOS 7 或 RHEL 7( Red Hat 企业版 Linux) 服务器上安装和配置 KVM(基于内核的虚拟机)？如何在 CnetOS 7 上设置 KMV 并使用云镜像/ cloud-init 来安装客户虚拟机？
|
||||
如何在 CnetOS 7 或 RHEL 7（Red Hat 企业版 Linux）服务器上安装和配置 KVM（基于内核的虚拟机）？如何在 CentOS 7 上设置 KVM 并使用云镜像 / cloud-init 来安装客户虚拟机？
|
||||
|
||||
基于内核的虚拟机（KVM）是 CentOS 或 RHEL 7 的虚拟化软件。KVM 可以将你的服务器变成虚拟机管理器。本文介绍如何在 CentOS 7 或 RHEL 7 中使用 KVM 设置和管理虚拟化环境。还介绍了如何使用命令行在物理服务器上安装和管理虚拟机（VM）。请确保在服务器的 BIOS 中启用了**虚拟化技术(VT)**。你也可以运行以下命令[测试 CPU 是否支持 Intel VT 和 AMD_V 虚拟化技术][1]。
|
||||
|
||||
基于内核的虚拟机（KVM）是 CentOS 或 RHEL 7 的虚拟化软件。KVM 将你的服务器变成虚拟机管理程序。本文介绍如何在 CentOS 7 或 RHEL 7 中使用 KVM 设置和管理虚拟化环境。还介绍了如何使用 CLI 在物理服务器上安装和管理虚拟机（VM）。确保在服务器的 BIOS 中启用了**虚拟化技术(vt)**。你也可以运行以下命令[测试 CPU 是否支持 Intel VT 和 AMD_V 虚拟化技术][1]。
|
||||
```
|
||||
$ lscpu | grep Virtualization
|
||||
Virtualization: VT-x
|
||||
```
|
||||
|
||||
### 按照 CentOS 7/RHEL 7 终端服务器上的 KVM 安装步骤进行操作
|
||||
按照 CentOS 7/RHEL 7 终端服务器上的 KVM 安装步骤进行操作。
|
||||
|
||||
#### 步骤 1: 安装 kvm
|
||||
### 步骤 1： 安装 kvm
|
||||
|
||||
输入以下 [yum 命令][2]:
|
||||
`# yum install qemu-kvm libvirt libvirt-python libguestfs-tools virt-install`
|
||||
|
||||
```
|
||||
# yum install qemu-kvm libvirt libvirt-python libguestfs-tools virt-install
|
||||
```
|
||||
|
||||
[![How to install KVM on CentOS 7 RHEL 7 Headless Server][3]][3]
|
||||
|
||||
启动 libvirtd 服务：
|
||||
|
||||
```
|
||||
# systemctl enable libvirtd
|
||||
# systemctl start libvirtd
|
||||
```
|
||||
|
||||
#### 步骤 2: 确认 kvm 安装
|
||||
### 步骤 2： 确认 kvm 安装
|
||||
|
||||
确保使用 lsmod 命令和 [grep命令][4] 加载 KVM 模块：
|
||||
`# lsmod | grep -i kvm`
|
||||
使用 `lsmod` 命令和 [grep命令][4] 确认加载了 KVM 模块：
|
||||
|
||||
#### 步骤 3: 配置桥接网络
|
||||
```
|
||||
# lsmod | grep -i kvm
|
||||
```
|
||||
|
||||
### 步骤 3： 配置桥接网络
|
||||
|
||||
默认情况下，由 libvirtd 配置基于 dhcpd 的网桥。你可以使用以下命令验证：
|
||||
|
||||
默认情况下，由 libvirtd 配置的基于 dhcpd 的网桥。你可以使用以下命令验证：
|
||||
```
|
||||
# brctl show
|
||||
# virsh net-list
|
||||
```
|
||||
|
||||
[![KVM default networking][5]][5]
|
||||
|
||||
所有虚拟机（客户机器）只能在同一台服务器上对其他虚拟机进行网络访问。为你创建的私有网络是 192.168.122.0/24。验证：
|
||||
`# virsh net-dumpxml default`
|
||||
所有虚拟机（客户机）只能对同一台服务器上的其它虚拟机进行网络访问。为你创建的私有网络是 192.168.122.0/24。验证：
|
||||
|
||||
```
|
||||
# virsh net-dumpxml default
|
||||
```
|
||||
|
||||
如果你希望你的虚拟机可用于 LAN 上的其他服务器，请在连接到你的 LAN 的服务器上设置一个网桥。更新你的网卡配置文件，如 ifcfg-enp3s0 或 em1：
|
||||
|
||||
```
|
||||
# vi /etc/sysconfig/network-scripts/ifcfg-enp3s0
|
||||
```
|
||||
|
||||
如果你希望你的虚拟机可用于 LAN 上的其他服务器，请在连接到你的 LAN 的服务器上设置一个网桥。更新你的网卡配置文件，如 ifcfg-enp3s0 或 em1:
|
||||
`# vi /etc/sysconfig/network-scripts/enp3s0 `
|
||||
添加一行：
|
||||
|
||||
```
|
||||
BRIDGE=br0
|
||||
```
|
||||
|
||||
[使用 vi 保存并关闭文件][6]。编辑 /etc/sysconfig/network-scripts/ifcfg-br0 :
|
||||
`# vi /etc/sysconfig/network-scripts/ifcfg-br0`
|
||||
添加以下东西：
|
||||
[使用 vi 保存并关闭文件][6]。编辑 `/etc/sysconfig/network-scripts/ifcfg-br0`：
|
||||
|
||||
```
|
||||
# vi /etc/sysconfig/network-scripts/ifcfg-br0
|
||||
```
|
||||
|
||||
添加以下内容：
|
||||
|
||||
```
|
||||
DEVICE="br0"
|
||||
# I am getting ip from DHCP server #
|
||||
@ -62,29 +85,38 @@ TYPE="Bridge"
|
||||
DELAY="0"
|
||||
```
|
||||
|
||||
重新启动网络服务（警告：ssh命令将断开连接，最好重新启动该设备）：
|
||||
`# systemctl restart NetworkManager`
|
||||
重新启动网络服务（警告：ssh 命令将断开连接，最好重新启动该设备）：
|
||||
|
||||
用 brctl 命令验证它：
|
||||
`# brctl show`
|
||||
```
|
||||
# systemctl restart NetworkManager
|
||||
```
|
||||
|
||||
#### 步骤 4: 创建你的第一个虚拟机
|
||||
用 `brctl` 命令验证它：
|
||||
|
||||
```
|
||||
# brctl show
|
||||
```
|
||||
|
||||
### 步骤 4： 创建你的第一个虚拟机
|
||||
|
||||
我将会创建一个 CentOS 7.x 虚拟机。首先，使用 `wget` 命令获取 CentOS 7.x 最新的 ISO 镜像：
|
||||
|
||||
我将会创建一个 CentOS 7.x 虚拟机。首先，使用 wget 命令获取 CentOS 7.x 最新的 ISO 镜像：
|
||||
```
|
||||
# cd /var/lib/libvirt/boot/
|
||||
# wget https://mirrors.kernel.org/centos/7.4.1708/isos/x86_64/CentOS-7-x86_64-Minimal-1708.iso
|
||||
```
|
||||
|
||||
验证 ISO 镜像：
|
||||
|
||||
```
|
||||
# wget https://mirrors.kernel.org/centos/7.4.1708/isos/x86_64/sha256sum.txt
|
||||
# sha256sum -c sha256sum.txt
|
||||
```
|
||||
|
||||
##### 创建 CentOS 7.x 虚拟机
|
||||
#### 创建 CentOS 7.x 虚拟机
|
||||
|
||||
在这个例子中，我创建了 2GB RAM，2 个 CPU 核心，1 个网卡和 40 GB 磁盘空间的 CentOS 7.x 虚拟机，输入：
|
||||
|
||||
```
|
||||
# virt-install \
|
||||
--virt-type=kvm \
|
||||
@ -98,35 +130,41 @@ DELAY="0"
|
||||
--disk path=/var/lib/libvirt/images/centos7.qcow2,size=40,bus=virtio,format=qcow2
|
||||
```
|
||||
|
||||
从另一个终端通过 ssh 和 type 配置 vnc 登录：
|
||||
从另一个终端通过 `ssh` 配置 vnc 登录，输入：
|
||||
|
||||
```
|
||||
# virsh dumpxml centos7 | grep v nc
|
||||
<graphics type='vnc' port='5901' autoport='yes' listen='127.0.0.1'>
|
||||
```
|
||||
|
||||
请记录下端口值（即 5901）。你需要使用 SSH 客户端来建立隧道和 VNC 客户端才能访问远程 vnc 服务区。在客户端/桌面/ macbook pro 系统中输入以下 SSH 端口转化命令：
|
||||
`$ ssh vivek@server1.cyberciti.biz -L 5901:127.0.0.1:5901`
|
||||
请记录下端口值（即 5901）。你需要使用 SSH 客户端来建立隧道和 VNC 客户端才能访问远程 vnc 服务器。在客户端/桌面/ macbook pro 系统中输入以下 SSH 端口转发命令：
|
||||
|
||||
```
|
||||
$ ssh vivek@server1.cyberciti.biz -L 5901:127.0.0.1:5901
|
||||
```
|
||||
|
||||
一旦你建立了 ssh 隧道，你可以将你的 VNC 客户端指向你自己的 127.0.0.1 (localhost) 地址和端口 5901，如下所示：
|
||||
|
||||
[![][7]][7]
|
||||
|
||||
你应该看到 CentOS Linux 7 客户虚拟机安装屏幕如下：
|
||||
|
||||
[![][8]][8]
|
||||
|
||||
现在只需按照屏幕说明进行操作并安装CentOS 7。一旦安装完成后，请继续并单击重启按钮。 远程服务器关闭了我们的 VNC 客户端的连接。 你可以通过 KVM 客户端重新连接，以配置服务器的其余部分，包括基于 SSH 的会话或防火墙。
|
||||
|
||||
#### 步骤 5: 使用云镜像
|
||||
### 使用云镜像
|
||||
|
||||
以上安装方法对于学习目的或单个虚拟机而言是可行的。你需要部署大量的虚拟机吗？ 尝试云镜像。你可以根据需要修改预先构建的云图像。例如，使用 [Cloud-init][9] 添加用户，ssh 密钥，设置时区等等，这是处理云实例的早期初始化的事实上的多分发包。让我们看看如何创建带有 1024MB RAM，20GB 磁盘空间和 1 个 vCPU 的 CentOS 7 虚拟机。（译注： vCPU 即电脑中的虚拟处理器）
|
||||
以上安装方法对于学习目的或单个虚拟机而言是可行的。你需要部署大量的虚拟机吗？ 可以试试云镜像。你可以根据需要修改预先构建的云镜像。例如，使用 [Cloud-init][9] 添加用户、ssh 密钥、设置时区等等，这是处理云实例的早期初始化的事实上的多分发包。让我们看看如何创建带有 1024MB RAM，20GB 磁盘空间和 1 个 vCPU 的 CentOS 7 虚拟机。（LCTT 译注： vCPU 即电脑中的虚拟处理器）
|
||||
|
||||
##### 获取 CentOS 7 云镜像
|
||||
#### 获取 CentOS 7 云镜像
|
||||
|
||||
```
|
||||
# cd /var/lib/libvirt/boot
|
||||
# wget http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2
|
||||
```
|
||||
|
||||
##### 创建所需的目录
|
||||
#### 创建所需的目录
|
||||
|
||||
```
|
||||
# D=/var/lib/libvirt/images
|
||||
@ -135,31 +173,39 @@ DELAY="0"
|
||||
mkdir: created directory '/var/lib/libvirt/images/centos7-vm1'
|
||||
```
|
||||
|
||||
##### 创建元数据文件
|
||||
#### 创建元数据文件
|
||||
|
||||
```
|
||||
# cd $D/$VM
|
||||
# vi meta-data
|
||||
```
|
||||
|
||||
添加以下东西：
|
||||
添加以下内容：
|
||||
|
||||
```
|
||||
instance-id: centos7-vm1
|
||||
local-hostname: centos7-vm1
|
||||
```
|
||||
|
||||
##### 创建用户数据文件
|
||||
#### 创建用户数据文件
|
||||
|
||||
我将使用 ssh 密钥登录到虚拟机。所以确保你有 ssh 密钥：
|
||||
|
||||
```
|
||||
# ssh-keygen -t ed25519 -C "VM Login ssh key"
|
||||
```
|
||||
|
||||
我将使用 ssh 密钥登录到虚拟机。所以确保你有 ssh-keys：
|
||||
`# ssh-keygen -t ed25519 -C "VM Login ssh key"`
|
||||
[![ssh-keygen command][10]][11]
|
||||
|
||||
请参阅 "[如何在 Linux/Unix 系统上设置 SSH 密钥][12]" 来获取更多信息。编辑用户数据如下：
|
||||
请参阅 “[如何在 Linux/Unix 系统上设置 SSH 密钥][12]” 来获取更多信息。编辑用户数据如下：
|
||||
|
||||
```
|
||||
# cd $D/$VM
|
||||
# vi user-data
|
||||
```
|
||||
添加如下（根据你的设置替换主机名，用户，ssh-authorized-keys）：
|
||||
|
||||
添加如下（根据你的设置替换 `hostname`、`users`、`ssh-authorized-keys`）：
|
||||
|
||||
```
|
||||
#cloud-config
|
||||
|
||||
@ -199,14 +245,14 @@ runcmd:
|
||||
- yum -y remove cloud-init
|
||||
```
|
||||
|
||||
##### 复制云镜像
|
||||
#### 复制云镜像
|
||||
|
||||
```
|
||||
# cd $D/$VM
|
||||
# cp /var/lib/libvirt/boot/CentOS-7-x86_64-GenericCloud.qcow2 $VM.qcow2
|
||||
```
|
||||
|
||||
##### 创建 20GB 磁盘映像
|
||||
#### 创建 20GB 磁盘映像
|
||||
|
||||
```
|
||||
# cd $D/$VM
|
||||
@ -215,25 +261,30 @@ runcmd:
|
||||
# virt-resize --quiet --expand /dev/sda1 $VM.qcow2 $VM.new.image
|
||||
```
|
||||
[![Set VM image disk size][13]][13]
|
||||
覆盖它的缩放图片:
|
||||
|
||||
用压缩后的镜像覆盖它：
|
||||
|
||||
```
|
||||
# cd $D/$VM
|
||||
# mv $VM.new.image $VM.qcow2
|
||||
```
|
||||
|
||||
##### 创建一个 cloud-init ISO
|
||||
#### 创建一个 cloud-init ISO
|
||||
|
||||
```
|
||||
# mkisofs -o $VM-cidata.iso -V cidata -J -r user-data meta-data
|
||||
```
|
||||
|
||||
`# mkisofs -o $VM-cidata.iso -V cidata -J -r user-data meta-data`
|
||||
[![Creating a cloud-init ISO][14]][14]
|
||||
|
||||
##### 创建一个 pool
|
||||
#### 创建一个池
|
||||
|
||||
```
|
||||
# virsh pool-create-as --name $VM --type dir --target $D/$VM
|
||||
Pool centos7-vm1 created
|
||||
```
|
||||
|
||||
##### 安装 CentOS 7 虚拟机
|
||||
#### 安装 CentOS 7 虚拟机
|
||||
|
||||
```
|
||||
# cd $D/$VM
|
||||
@ -247,23 +298,31 @@ Pool centos7-vm1 created
|
||||
--graphics spice \
|
||||
--noautoconsole
|
||||
```
|
||||
|
||||
删除不需要的文件：
|
||||
|
||||
```
|
||||
# cd $D/$VM
|
||||
# virsh change-media $VM hda --eject --config
|
||||
# rm meta-data user-data centos7-vm1-cidata.iso
|
||||
```
|
||||
|
||||
##### 查找虚拟机的 IP 地址
|
||||
#### 查找虚拟机的 IP 地址
|
||||
|
||||
`# virsh net-dhcp-leases default`
|
||||
```
|
||||
# virsh net-dhcp-leases default
|
||||
```
|
||||
|
||||
[![CentOS7-VM1- Created][15]][15]
|
||||
|
||||
##### 登录到你的虚拟机
|
||||
#### 登录到你的虚拟机
|
||||
|
||||
使用 ssh 命令：
|
||||
|
||||
```
|
||||
# ssh vivek@192.168.122.85
|
||||
```
|
||||
|
||||
使用 ssh 命令:
|
||||
`# ssh vivek@192.168.122.85`
|
||||
[![Sample VM session][16]][16]
|
||||
|
||||
### 有用的命令
|
||||
@ -272,7 +331,9 @@ Pool centos7-vm1 created
|
||||
|
||||
#### 列出所有虚拟机
|
||||
|
||||
`# virsh list --all`
|
||||
```
|
||||
# virsh list --all
|
||||
```
|
||||
|
||||
#### 获取虚拟机信息
|
||||
|
||||
@ -283,21 +344,33 @@ Pool centos7-vm1 created
|
||||
|
||||
#### 停止/关闭虚拟机
|
||||
|
||||
`# virsh shutdown centos7-vm1`
|
||||
```
|
||||
# virsh shutdown centos7-vm1
|
||||
```
|
||||
|
||||
#### 开启虚拟机
|
||||
|
||||
`# virsh start centos7-vm1`
|
||||
```
|
||||
# virsh start centos7-vm1
|
||||
```
|
||||
|
||||
#### 将虚拟机标记为在引导时自动启动
|
||||
|
||||
`# virsh autostart centos7-vm1`
|
||||
```
|
||||
# virsh autostart centos7-vm1
|
||||
```
|
||||
|
||||
#### 重新启动（软安全重启）虚拟机
|
||||
|
||||
`# virsh reboot centos7-vm1`
|
||||
```
|
||||
# virsh reboot centos7-vm1
|
||||
```
|
||||
|
||||
重置（硬重置/不安全）虚拟机
|
||||
`# virsh reset centos7-vm1`
|
||||
|
||||
```
|
||||
# virsh reset centos7-vm1
|
||||
```
|
||||
|
||||
#### 删除虚拟机
|
||||
|
||||
@ -309,7 +382,9 @@ Pool centos7-vm1 created
|
||||
# VM=centos7-vm1
|
||||
# rm -ri $D/$VM
|
||||
```
|
||||
查看 virsh 命令类型的完整列表
|
||||
|
||||
查看 virsh 命令类型的完整列表：
|
||||
|
||||
```
|
||||
# virsh help | less
|
||||
# virsh help | grep reboot
|
||||
@ -321,11 +396,11 @@ Pool centos7-vm1 created
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: [https://www.cyberciti.biz/faq/how-to-install-kvm-on-centos-7-rhel-7-headless-server/](https://www.cyberciti.biz/faq/how-to-install-kvm-on-centos-7-rhel-7-headless-server/)
|
||||
via: https://www.cyberciti.biz/faq/how-to-install-kvm-on-centos-7-rhel-7-headless-server/
|
||||
|
||||
作者：[Vivek Gite][a]
|
||||
译者：[MjSeven](https://github.com/MjSeven)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -0,0 +1,61 @@
|
||||
LKRG：用于运行时完整性检查的可加载内核模块
|
||||
======
|
||||
![LKRG logo][1]
|
||||
|
||||
开源社区的人们正在致力于一个 Linux 内核的新项目，它可以让内核更安全。命名为 Linux 内核运行时防护（Linux Kernel Runtime Guard，简称：LKRG），它是一个在 Linux 内核执行运行时完整性检查的可加载内核模块（LKM）。
|
||||
|
||||
它的用途是检测对 Linux 内核的已知的或未知的安全漏洞利用企图，以及去阻止这种攻击企图。
|
||||
|
||||
LKRG 也可以检测正在运行的进程的提权行为，在漏洞利用代码运行之前杀掉这个运行进程。
|
||||
|
||||
### 这个项目开发始于 2011 年，首个版本已经发布
|
||||
|
||||
因为这个项目开发的较早，LKRG 的当前版本仅仅是通过内核消息去报告违反内核完整性的行为，但是随着这个项目的成熟，将会部署一个完整的漏洞利用缓减系统。
|
||||
|
||||
LKRG 的成员 Alexander Peslyak 解释说，这个项目从 2011 年启动，并且 LKRG 已经经历了一个“重新开发"阶段。
|
||||
|
||||
LKRG 的首个公开版本是 LKRG v0.0，它现在可以从 [这个页面][2] 下载使用。[这里][3] 是这个项目的维基，为支持这个项目，它也有一个 [Patreon 页面][4]。
|
||||
|
||||
虽然 LKRG 仍然是一个开源项目，LKRG 的维护者也计划做一个 LKRG Pro 版本，这个版本将包含一个专用的 LKRG 发行版，它将支持对特定漏洞利用的检测，比如，容器泄漏。开发团队计划从 LKRG Pro 基金中提取部分资金用于保证项目的剩余工作。
|
||||
|
||||
### LKRG 是一个内核模块而不是一个补丁。
|
||||
|
||||
一个类似的项目是<ruby>附加内核监视器<rt>Additional Kernel Observer</rt></ruby>（AKO），但是 LKRG 与 AKO 是不一样的，因为 LKRG 是一个内核加载模块而不是一个补丁。LKRG 开发团队决定将它设计为一个内核模块是因为，在内核上打补丁对安全性、系统稳定性以及性能都有很直接的影响。
|
||||
|
||||
而以内核模块的方式提供，可以在每个系统上更容易部署 LKRG，而不必去修改核心的内核代码，修改核心的内核代码非常复杂并且很容易出错。
|
||||
|
||||
LKRG 内核模块在目前主流的 Linux 发行版上都可以使用，比如，RHEL7、OpenVZ 7、Virtuozzo 7、以及 Ubuntu 16.04 到最新的主线版本。
|
||||
|
||||
### 它并非是一个完美的解决方案
|
||||
|
||||
LKRG 的创建者警告用户，他们并不认为 LKRG 是一个完美的解决方案，它**提供不了**坚不可摧和 100% 的安全。他们说，LKRG 是 “设计为**可旁通**的”，并且仅仅提供了“多元化安全” 的**一个**方面。
|
||||
|
||||
> 虽然 LKRG 可以防御许多已有的 Linux 内核漏洞利用，而且也有可能会防御将来许多的（包括未知的）未特意设计去绕过 LKRG 的安全漏洞利用。它是设计为可旁通的（尽管有时候是以更复杂和/或低可利用为代价的）。因此，他们说 LKRG 通过多元化提供安全，就像运行一个不常见的操作系统内核一样，也就不会有真实运行一个不常见的操作系统的可用性弊端。
|
||||
|
||||
LKRG 有点像基于 Windows 的防病毒软件，它也是工作于内核级别去检测漏洞利用和恶意软件。但是，LKRG 团队说，他们的产品比防病毒软件以及其它终端安全软件更加安全，因为它的基础代码量比较小，所以在内核级别引入新 bug 和漏洞的可能性就更小。
|
||||
|
||||
### 运行当前版本的 LKRG 大约会带来 6.5% 的性能损失
|
||||
|
||||
Peslyak 说 LKRG 是非常适用于 Linux 机器的，它在修补内核的安全漏洞后不需要重启动机器。LKRG 允许用户持续运行带有安全措施的机器，直到在一个计划的维护窗口中测试和部署关键的安全补丁为止。
|
||||
|
||||
经测试显示，安装 LKRG v0.0 后大约会产生 6.5% 性能影响，但是，Peslyak 说将在后续的开发中持续降低这种影响。
|
||||
|
||||
测试也显示，LKRG 检测到了 CVE-2014-9322 (BadIRET)、CVE-2017-5123 (waitid(2) missing access_ok)、以及 CVE-2017-6074 (use-after-free in DCCP protocol) 的漏洞利用企图，但是没有检测到 CVE-2016-5195 (Dirty COW) 的漏洞利用企图。开发团队说，由于前面提到的“可旁通”的设计策略，LKRG 没有检测到 Dirty COW 提权攻击。
|
||||
|
||||
> 在 Dirty COW 的测试案例中，由于 bug 机制的原因，使得 LKRG 发生了 “旁通”，并且这也是一种利用方法，它也是将来类似的以用户空间为目标的绕过 LKRG 的一种方法。这样的漏洞利用是否会是普通情况（不太可能！除非 LKRG 或者类似机制的软件流行起来），以及对它的可用性的（负面的）影响是什么？（对于那些直接目标是用户空间的内核漏洞来说，这不太重要，也并不简单）。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.bleepingcomputer.com/news/linux/lkrg-linux-to-get-a-loadable-kernel-module-for-runtime-integrity-checking/
|
||||
|
||||
作者：[Catalin Cimpanu][a]
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.bleepingcomputer.com/author/catalin-cimpanu/
|
||||
[1]:https://www.bleepstatic.com/content/posts/2018/02/04/LKRG-logo.png
|
||||
[2]:http://www.openwall.com/lkrg/
|
||||
[3]:http://openwall.info/wiki/p_lkrg/Main
|
||||
[4]:https://www.patreon.com/p_lkrg
|
||||
@ -1,59 +0,0 @@
|
||||
Translating by qhwdw
|
||||
Will DevOps steal my job?
|
||||
======
|
||||
|
||||
>Are you worried automation will replace people in the workplace? You may be right, but here's why that's not a bad thing.
|
||||
|
||||
|
||||
>Image by : opensource.com
|
||||
|
||||
It's a common fear: Will DevOps be the end of my job? After all, DevOps means developers doing operations, right? DevOps is automation. What if I automate myself out of a job? Do continuous delivery and containers mean operations staff are obsolete? DevOps is all about coding: infrastructure-as-code and testing-as-code and this-or-that-as-code. What if I don't have the skill set to be a part of this?
|
||||
|
||||
[DevOps][1] is a looming change, disruptive in the field, with seemingly fanatical followers talking about changing the world with the [Three Ways][2]--the three underpinnings of DevOps--and the tearing down of walls. It can all be overwhelming. So what's it going to be--is DevOps going to steal my job?
|
||||
|
||||
### The first fear: I'm not needed
|
||||
|
||||
As developers managing the entire lifecycle of an application, it's all too easy to get caught up in the idea of DevOps. Containers are probably a big contributing factor to this line of thought. When containers exploded onto the scene, they were touted as a way for developers to build, test, and deploy their code all-in-one. What role does DevOps leave for the operations team, or testing, or QA?
|
||||
|
||||
This stems from a misunderstanding of the principles of DevOps. The first principle of DevOps, or the First Way, is _Systems Thinking_ , or placing emphasis on a holistic approach to managing and understanding the whole lifecycle of an application or service. This does not mean that the developers of the application learn and manage the whole process. Rather, it is the collaboration of talented and skilled individuals to ensure success as a whole. To make developers solely responsible for the process is practically the extreme opposite of this tenant--essentially the enshrining of a single silo with the importance of the entire lifecycle.
|
||||
|
||||
There is a place for specialization in DevOps. Just as the classically educated software engineer with knowledge of linear regression and binary search is wasted writing Ansible playbooks and Docker files, the highly skilled sysadmin with the knowledge of how to secure a system and optimize database performance is wasted writing CSS and designing user flows. The most effective group to write, test, and maintain an application is a cross-discipline, functional team of people with diverse skill sets and backgrounds.
|
||||
|
||||
### The second fear: My job will be automated
|
||||
|
||||
Accurate or not, DevOps can sometimes be seen as a synonym for automation. What work is left for operations staff and testing teams when automated builds, testing, deployment, monitoring, and notifications are a huge part of the application lifecycle? This focus on automation can be partially related to the Second Way: _Amplify Feedback Loops_. This second tenant of DevOps deals with prioritizing quick feedback between teams in the opposite direction an application takes to deployment --from monitoring and maintaining to deployment, testing, development, etc., and the emphasis to make the feedback important and actionable. While the Second Way is not specifically related to automation, many of the automation tools teams use within their deployment pipelines facilitate quick notification and quick action, or course-correction based on feedback in support of this tenant. Traditionally done by humans, it is easy to understand why a focus on automation might lead to anxiety about the future of one's job.
|
||||
|
||||
Automation is just a tool, not a replacement for people. Smart people trapped doing the same things over and over, pushing the big red George Jetson button are a wasted, untapped wealth of intelligence and creativity. Automation of the drudgery of daily work means more time to spend solving real problems and coming up with creative solutions. Humans are needed to figure out the "how and why;" computers can handle the "copy and paste."
|
||||
|
||||
There will be no end of repetitive, predictable things to automate, and automation frees teams to focus on higher-order tasks in their field. Monitoring teams, no longer spending all their time configuring alerts or managing trending configuration, can start to focus on predicting alarms, correlating statistics, and creating proactive solutions. Systems administrators, freed of scheduled patching or server configuration, can spend time focusing on fleet management, performance, and scaling. Unlike the striking images of factory floors and assembly lines totally devoid of humans, automated tasks in the DevOps world mean humans can focus on creative, rewarding tasks instead of mind-numbing drudgery.
|
||||
|
||||
### The third fear: I do not have the skillset for this
|
||||
|
||||
"How am I going to keep up with this? I don't know how to automate. Everything is code now--do I have to be a developer and write code for a living to work in DevOps?" The third fear is ultimately a fear of self-confidence. As the culture changes, yes, teams will be asked to change along with it, and some may fear they lack the skills to perform what their jobs will become.
|
||||
|
||||
Most folks, however, are probably already closer than they think. What is the Dockerfile, or configuration management like Puppet or Ansible, but environment as code? System administrators already write shell scripts and Python programs to handle repetitive tasks for them. It's hardly a stretch to learn a little more and begin using some of the tools already at their disposal to solve more problems--orchestration, deployment, maintenance-as-code--especially when freed from the drudgery of manual tasks to focus on growth.
|
||||
|
||||
The answer to this fear lies in the third tenant of DevOps, the Third Way: _A Culture of Continual Experimentation and Learning_. The ability to try and fail and learn from mistakes without blame is a major factor in creating ever-more creative solutions. The Third Way is empowered by the first two ways --allowing for for quick detection of and repair of problems, and just as the developer is free to try and learn, other teams are as well. Operations teams that have never used configuration management or written programs to automate infrastructure provisioning are free to try and learn. Testing and QA teams are free to implement new testing pipelines and automate approval and release processes. In a culture that embraces learning and growing, everyone has the freedom to acquire the skills they need to succeed at and enjoy their job.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Any disruptive practice or change in an industry can create fear or uncertainty, and DevOps is no exception. A concern for one's job is a reasonable response to the hundreds of articles and presentations enumerating the countless practices and technologies seemingly dedicated to empowering developers to take responsibility for every aspect of the industry.
|
||||
|
||||
In truth, however, DevOps is "[a cross-disciplinary community of practice dedicated to the study of building, evolving, and operating rapidly changing resilient systems at scale][3]." DevOps means the end of silos, but not specialization. It is the delegation of drudgery to automated systems, freeing you to do what people do best: think and imagine. And if you're motivated to learn and grow, there will be no end of opportunities to solve new and challenging problems.
|
||||
|
||||
Will DevOps take away your job? Yes, but it will give you a better one.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/12/will-devops-steal-my-job
|
||||
|
||||
作者：[Chris Collins][a]
|
||||
译者：[译者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/clcollins
|
||||
[1]:https://opensource.com/resources/devops
|
||||
[2]:http://itrevolution.com/the-three-ways-principles-underpinning-devops/
|
||||
[3]:https://theagileadmin.com/what-is-devops/
|
||||
58
translated/tech/20171213 Will DevOps steal my job-.md
Normal file
58
translated/tech/20171213 Will DevOps steal my job-.md
Normal file
@ -0,0 +1,58 @@
|
||||
DevOps 将让你失业？
|
||||
======
|
||||
|
||||
>你是否担心工作中自动化将代替人？可能是对的，但是这并不是件坏事。
|
||||
|
||||
|
||||
>Image by : opensource.com
|
||||
|
||||
这是一个很正常的担心：DevOps 最终会让你失业？毕竟，DevOps 意味着开发人员做运营，对吗？DevOps 是自动化的。如果我的工作都自动化了，我去做什么？实行持续分发和容器化意味着运营已经过时了吗？对于 DevOps 来说，所有的东西都是代码：基础设施是代码、测试是代码、这个和那个都是代码。如果我没有这些技能怎么办？
|
||||
|
||||
[DevOps][1] 是一个即将到来的变化，将颠覆这一领域，狂热的拥挤者们正在谈论，如何使用 [三种方法][2] 去改变世界 —— 即 DevOps 的三大基础 —— 去推翻一个旧的世界。它是势不可档的。那么，问题来了 —— DevOps 将会让我失业吗？
|
||||
|
||||
### 第一个担心：再也不需要我了
|
||||
|
||||
由于开发者来管理应用程序的整个生命周期，接受 DevOps 的理念很容易。容器化可能是影响这一想法的重要因素。当容器化在各种场景下铺开之后，它们被吹嘘成开发者构建、测试、和部署他们代码的一站式解决方案。DevOps 对于运营、测试、以及 QA 团队来说，有什么作用呢？
|
||||
|
||||
这源于对 DevOps 原则的误解。DevOps 的第一原则，或者第一方法是，_系统思考_ ，或者强调整体管理方法和了解应用程序或服务的整个生命周期。这并不意味着应用程序的开发者将学习和管理整个过程。相反，是拥有各个专业和技能的人共同合作，以确保成功。让开发者对这一过程完全负责的作法，几乎是将开发者置于使用者的对立面—— 本质上就是 “将鸡蛋放在了一个篮子里”。
|
||||
|
||||
在 DevOps 中有一个为你保留的专门职位。就像将一个受过传统教育的、拥有线性回归和二分查找知识的软件工程师，被用去写一些 Ansible playbooks 和 Docker 文件，这是一种浪费。而对于那些拥有高级技能，知道如何保护一个系统和优化数据库执行的系统管理员，被浪费在写一些 CSS 和设计用户流这样的工作上。写代码、做测试、和维护应用程序的高效团队一般是跨学科、跨职能的、拥有不同专业技术和背景的人组成的混编团队。
|
||||
|
||||
### 第二个担心：我的工作将被自动化
|
||||
|
||||
或许是，或许不是，DevOps 可能在有时候是自动化的同义词。当自动化构建、测试、部署、监视、以及提醒等事项，已经占据了整个应用程序生命周期管理的时候，还会给我们剩下什么工作呢？这种对自动化的关注可能与第二个方法有关：_放大反馈循环_。DevOps 的第二个方法是在团队和部署的应用程序之间，采用相反的方向优先处理快速反馈 —— 从监视和维护部署、测试、开发、等等，通过强调，使反馈更加重要并且可操作。虽然这第二种方式与自动化并不是特别相关，许多自动化工具团队在它们的部署流水线中使用，以促进快速提醒和快速行动，或者基于对使用者的支持业务中产生的反馈来改进。传统的做法是靠人来完成的，这就可以理解为什么自动化可能会导致未来一些人失业的焦虑了。
|
||||
|
||||
自动化只是一个工具，它并不能代替人。聪明的人使用它来做一些重复的工作，不去开发智力和创造性的财富，而是去按红色的 “George Jetson” 按钮是一种极大的浪费。让每天工作中的苦活自动化，意味着有更多的时间去解决真正的问题和即将到来的创新的解决方案。人类需要解决更多的 “怎么做和为什么” 问题，而计算机只能处理 “复制和粘贴”。
|
||||
|
||||
并不会仅限于在可重复的、可预见的事情上进行自动化，自动化让团队有更多的时间和精力去专注于本领域中更高级别的任务上。监视团队不再花费他们的时间去配置报警或者管理传统的配置，它们可能专注于预测可能的报警、相关性统计、以及设计可能的预案。系统管理员从计划补丁或服务器配置中解放出来，可以花费更多的时间专注于整体管理、性能、和可伸缩性。与工厂车间和装配线上完全没有人的景像不同，DevOps 中的自动化任务，意味着人更多关注于创造性的、有更高价值的任务，而不是一些重复的、让人麻木的苦差事。
|
||||
|
||||
### 第三个担心：我没有这些技能怎么办
|
||||
|
||||
"我怎么去继续做这些事情？我不懂如何自动化。现在所有的工作都是代码 —— 我不是开发人员，我不会做 DevOps 中写代码的工作“，第三个担心是一种不自信的担心。由于文化的改变，是的，团队将也会要求随之改变，一些人可能担心，他们缺乏继续做他们工作的技能。
|
||||
|
||||
然而，大多数人或许已经比他们所想的更接近。Dockerfile 是什么，或者像 Puppet 或 Ansible 配置管理是什么，但是环境即代码，系统管理员已经写了 shell 脚本和 Python 程序去处理他们重复的任务。学习更多的知识并使用已有的工具处理他们的更多问题 —— 编排、部署、维护即代码 —— 尤其是当从繁重的手动任务中解放出来，专注于成长时。
|
||||
|
||||
在 DevOps 的使用者中去回答这第三个担心，第三个方法是：_一种不断实验和学习的文化_。尝试、失败、并从错误中吸取教训而不是责怪它们的能力，是设计出更有创意的解决方案的重要因素。第三个方法是为前两个方法授权—— 允许快速检测和修复问题，并且开发人员可以自由地尝试和学习，其它的团队也是如此。从未使用过配置管理或者写过自动供给基础设施程序的运营团队也要自由尝试并学习。测试和 QA 团队也要自由实现新测试流水线，并且自动批准和发布新流程。在一个拥抱学习和成长的文化中，每个人都可以自由地获取他们需要的技术，去享受工作带来的成功和喜悦。
|
||||
|
||||
### 结束语
|
||||
|
||||
在一个行业中，任何可能引起混乱的实践或变化都会产生担心和不确定，DevOps 也不例外。对自己工作的担心是对成百上千的文章和演讲的合理回应，其中列举了无数的实践和技术，而这些实践和技术正致力于授权开发者对行业的各个方面承担职责。
|
||||
|
||||
然而，事实上，DevOps 是 "[一个跨学科的沟通实践，致力于研究构建、进化、和运营快速变化的弹性系统][3]"。 DevOps 意味着终结 ”筒仓“，但并不专业化。它是受委托去做苦差事的自动化系统，解放你，让你去做人类更擅长做的事：思考和想像。并且，如果你愿意去学习和成长，它将不会终结你解决新的、挑战性的问题的机会。
|
||||
|
||||
DevOps 会让你失业吗？会的，但它同时给你提供了更好的工作。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/12/will-devops-steal-my-job
|
||||
|
||||
作者：[Chris Collins][a]
|
||||
译者：[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/clcollins
|
||||
[1]:https://opensource.com/resources/devops
|
||||
[2]:http://itrevolution.com/the-three-ways-principles-underpinning-devops/
|
||||
[3]:https://theagileadmin.com/what-is-devops/
|
||||
@ -1,65 +0,0 @@
|
||||
LKRG：Linux 的适用于运行时完整性检查的可加载内核模块
|
||||
======
|
||||
![LKRG logo][1]
|
||||
|
||||
开源社区的成员正在致力于一个 Linux 内核的新项目，它可以让内核更安全。命名为 Linux 内核运行时防护（Linux Kernel Runtime Guard，简称：LKRG），它是一个在 Linux 内核执行运行时完整性检查时的可加载内核模块。
|
||||
|
||||
它的用途是检测对 Linux 内核的已知的或未知的安全漏洞利用企图，以及去阻止这种攻击企图。
|
||||
|
||||
LKRG 也可以检测正在运行的进程的提权行为，在漏洞利用代码运行之前杀掉这个运行进程。
|
||||
|
||||
### 这个项目从 2011 年开始开发以来，首个版本已经发布。
|
||||
|
||||
因为这个项目开发的较早，LKRG 的当前版本仅仅是通过内核消息去报告违反内核完整性的行为，但是随着这个项目的成熟，一个完整的漏洞利用缓减系统将会部署。
|
||||
|
||||
LKRG 的成员 Alexander Peslyak 解释说，这个项目从 2011 年启动，并且 LKRG 已经经历了“预开发"阶段。
|
||||
|
||||
LKRG 的首个公开版本是 — LKRG v0.0 — 它现在可以从 [这个页面][2] 下载使用。[这里][3] 是这个项目的维基，为支持这个项目，它也有一个 [Patreon 页面][4]。
|
||||
|
||||
虽然 LKRG 还是一个开源项目，LKRG 的维护者也计划做一个 LKRG Pro 版本，这个版本将包含一个专用的 LKRG 发行版，它将支持对特定漏洞利用的检测，比如，容器泄漏。开发团队计划从 LKRG Pro 基金中提取部分资金用于保证项目的剩余工作。
|
||||
|
||||
### LKRG 是一个内核模块而不是一个补丁。
|
||||
|
||||
一个类似的项目是去增加一个内核监视功能（AKO），但是 LKRG 与 AKO 是不一样的，因为 LKRG 是一个内核加载模式而不是一个补丁。LKRG 开发团队决定将它设计为一个内核模块是因为，在内核上打补丁对安全性、系统稳定性以及性能都有很直接的影响。
|
||||
|
||||
而作为内核模块的方式，可以在每个系统上更容易部署去 LKRG，而不必去修改核心的内核代码，修改核心的内核代码非常复杂并且很容易出错。
|
||||
|
||||
LKRG 内核模块在目前主流的 Linux 发行版上都可以使用，比如，RHEL7、OpenVZ 7、Virtuozzo 7、以及 Ubuntu 16.04 到最新的主线版本。
|
||||
|
||||
### 它并非是一个完美的解决方案
|
||||
|
||||
LKRG 的创建者警告用户，他们并不认为 LKRG 是一个完美的解决方案，它**提供不了**坚不可摧和 100% 的安全。他们说，LKRG 是 "设计为**可旁通**的"，并且仅仅提供了"多元化安全" 的**一个**方面。
|
||||
|
||||
```
|
||||
虽然 LKRG 可以防御许多对 Linux 内核的已存在的漏洞利用，而且也有可能会防御将来许多的（包括未知的）未特意设计去绕过 LKRG 的安全漏洞利用。它是设计为可旁通的（尽管有时候是以更复杂和/或低可利用为代价的）。因此，他们说 LKRG 通过多元化提供安全，就像运行一个不常见的操作系统内核一样，也就不会有真实运行一个不常见的操作系统的可用性弊端。
|
||||
```
|
||||
|
||||
LKRG 有点像基于 Windows 的防病毒软件，它也是工作于内核级别去检测漏洞利用和恶意软件。但是，LKRG 团队说，他们的产品比防病毒软件以及其它终端安全软件更加安全，因为它的基础代码量比较小，所以在内核级别引入新 bug 和漏洞的可能性就更小。
|
||||
|
||||
### 运行当前版本的 LKRG 大约会带来 6.5% 的性能损失
|
||||
|
||||
Peslyak 说 LKRG 是非常适用于 Linux 机器的，它在修补内核的安全漏洞后不需要重启动机器。LKRG 允许用户去持续运行带有安全措施的机器，直到在一个计划的维护窗口中测试和部署关键的安全补丁为止。
|
||||
|
||||
经测试显示，安装 LKRG v0.0 后大约会产生 6.5% 性能影响，但是，Peslyak 说将在后续的开发中持续降低这种影响。
|
||||
|
||||
测试也显示，LKRG 检测到了 CVE-2014-9322 (BadIRET)、CVE-2017-5123 (waitid(2) missing access_ok)、以及 CVE-2017-6074 (use-after-free in DCCP protocol) 的漏洞利用企图，但是没有检测到 CVE-2016-5195 (Dirty COW) 的漏洞利用企图。开发团队说，由于前面提到的”可旁通“的设计策略，LKRG 没有检测到 Dirty COW 提权攻击。
|
||||
|
||||
```
|
||||
在 Dirty COW 的测试案例中，由于 bug 机制的原因，使得 LKRG 发生了 "旁通"，并且这也是一种利用方法，它也是将来类似的以用户空间为目标的绕过 LKRG 的一种方法。这样的漏洞利用是否会是普通情况（不太可能！除非 LKRG 或者类似机制的软件流行起来），以及对它的可用性的（负面的）影响是什么？（对于那些直接目标是用户空间的内核漏洞来说，这不太重要，也并不简单）。
|
||||
```
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.bleepingcomputer.com/news/linux/lkrg-linux-to-get-a-loadable-kernel-module-for-runtime-integrity-checking/
|
||||
|
||||
作者：[Catalin Cimpanu][a]
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.bleepingcomputer.com/author/catalin-cimpanu/
|
||||
[1]:https://www.bleepstatic.com/content/posts/2018/02/04/LKRG-logo.png
|
||||
[2]:http://www.openwall.com/lkrg/
|
||||
[3]:http://openwall.info/wiki/p_lkrg/Main
|
||||
[4]:https://www.patreon.com/p_lkrg
|
||||
Loading…
Reference in New Issue
Block a user