Linux 文件系统多年来在不断发展，让我们来看一下文件系统类型。

虽然对于普通用户来说可能并不明显，但在过去十年左右的时间里，Linux 文件系统已经发生了显著的变化，这使它们能够更好对抗损坏和性能问题。

如今大多数 Linux 系统使用名为 ext4 的文件系统。 “ext” 代表“ 扩展 extended ”，“4” 表示这是此文件系统的第 4 代。随着时间的推移添加的功能包括：能够提供越来越大的文件系统（目前大到 1,000,000 TiB）和更大的文件（高达 16 TiB），更抗系统崩溃，更少碎片（将单个文件分散为存在多个位置的块）以提高性能。

ext4 文件系统还带来了对性能、可伸缩性和容量的其他改进。实现了元数据和日志校验和以增强可靠性。时间戳现在可以跟踪纳秒级变化，以便更好地对文件打戳（例如，文件创建和最后更新时间）。并且，在时间戳字段中增加了两个位，2038 年的问题（存储日期/时间的字段将从最大值翻转到零）已被推迟到了 400 多年之后（到 2446）。

文件系统类型

要确定 Linux 系统上文件系统的类型，请使用 df 命令。下面显示的命令中的 -T 选项显示文件系统类型。 -h 显示“易读的”磁盘大小。换句话说，调整报告的单位（如 M 和 G），使人们更好地理解。

$ df -hT | head -10
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  2.9G     0  2.9G   0% /dev
tmpfs          tmpfs     596M  1.5M  595M   1% /run
/dev/sda1      ext4      110G   50G   55G  48% /
/dev/sdb2      ext4      457G  642M  434G   1% /apps
tmpfs          tmpfs     3.0G     0  3.0G   0% /dev/shm
tmpfs          tmpfs     5.0M  4.0K  5.0M   1% /run/lock
tmpfs          tmpfs     3.0G     0  3.0G   0% /sys/fs/cgroup
/dev/loop0     squashfs   89M   89M     0 100% /snap/core/7270
/dev/loop2     squashfs  142M  142M     0 100% /snap/hexchat/42

请注意，/（根）和 /apps 的文件系统都是 ext4，而 /dev 是 devtmpfs 文件系统（一个由内核填充的自动化设备节点）。其他的文件系统显示为 tmpfs（驻留在内存和/或交换分区中的临时文件系统）和 squashfs（只读压缩文件系统的文件系统，用于快照包）。

还有 proc 文件系统，用于存储正在运行的进程的信息。

$ df -T /proc
Filesystem     Type 1K-blocks  Used Available Use% Mounted on
proc           proc         0     0         0    - /proc

当你在整个文件系统中游览时，可能会遇到许多其他文件系统类型。例如，当你移动到目录中并想了解它的文件系统时，可以运行以下命令：

$ cd /dev/mqueue; df -T .
Filesystem     Type   1K-blocks  Used Available Use% Mounted on
mqueue         mqueue         0     0         0    - /dev/mqueue
$ cd /sys; df -T .
Filesystem     Type  1K-blocks  Used Available Use% Mounted on
sysfs          sysfs         0     0         0    - /sys
$ cd /sys/kernel/security; df -T .
Filesystem     Type       1K-blocks  Used Available Use% Mounted on
securityfs     securityfs         0     0         0    - /sys/kernel/security

与其他 Linux 命令一样，这里的 . 代表整个文件系统的当前位置。

这些和其他独特的文件系统提供了一些特殊功能。例如，securityfs 提供支持安全模块的文件系统。

Linux 文件系统需要能够抵抗损坏，能够承受系统崩溃并提供快速、可靠的性能。由几代 ext 文件系统和新一代专用文件系统提供的改进使 Linux 系统更易于管理和更可靠。

via: https://www.networkworld.com/article/3432990/a-guided-tour-of-linux-file-system-types.html

作者：Sandra Henry-Stocker 选题：lujun9972 译者：geekpi 校对：wxy

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

本指南介绍了如何查找 Linux 发行版名称、版本和内核详细信息。如果你的 Linux 系统有 GUI 界面，那么你可以从系统设置中轻松找到这些信息。但在命令行模式下，初学者很难找到这些详情。没有问题！我这里给出了一些命令行方法来查找 Linux 系统信息。可能有很多，但这些方法适用于大多数 Linux 发行版。

1、查找 Linux 发行版名称、版本

有很多方法可以找出 VPS 中运行的操作系统。

方法 1：

打开终端并运行以下命令：

$ cat /etc/*-release

CentOS 7 上的示例输出：

CentOS Linux release 7.0.1406 (Core)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CentOS Linux release 7.0.1406 (Core)
CentOS Linux release 7.0.1406 (Core)

Ubuntu 18.04 上的示例输出：

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"
NAME="Ubuntu"
VERSION="18.04.2 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.2 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

方法 2：

以下命令也能获取你发行版的详细信息。

$ cat /etc/issue

Ubuntu 18.04 上的示例输出：

Ubuntu 18.04.2 LTS \n \l

方法 3：

以下命令能在 Debian 及其衍生版如 Ubuntu、Linux Mint 上获取发行版详细信息。

$ lsb_release -a

示例输出：

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:    18.04
Codename:   bionic

2、查找 Linux 内核详细信息

方法 1：

要查找 Linux 内核详细信息，请在终端运行以下命令。

$ uname -a

CentOS 7 上的示例输出：

Linux server.ostechnix.lan 3.10.0-123.9.3.el7.x86_64 #1 SMP Thu Nov 6 15:06:03 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Ubuntu 18.04 上的示例输出：

Linux ostechnix 4.18.0-25-generic #26~18.04.1-Ubuntu SMP Thu Jun 27 07:28:31 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

或者，

$ uname -mrs

示例输出：

Linux 4.18.0-25-generic x86_64

这里，

• Linux – 内核名
• 4.18.0-25-generic – 内核版本
• x86_64 – 系统硬件架构（即 64 位系统）

有关 uname 命令的更多详细信息，请参考手册页。

$ man uname

方法2：

在终端中，运行以下命令：

$ cat /proc/version

CentOS 7 上的示例输出：

Linux version 3.10.0-123.9.3.el7.x86_64 ([email protected]) (gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) ) #1 SMP Thu Nov 6 15:06:03 UTC 2014

Ubuntu 18.04 上的示例输出：

Linux version 4.18.0-25-generic ([email protected]) (gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)) #26~18.04.1-Ubuntu SMP Thu Jun 27 07:28:31 UTC 2019

这些是查找 Linux 发行版的名称、版本和内核详细信息的几种方法。希望你觉得它有用。

via: https://www.ostechnix.com/find-out-the-linux-distribution-name-version-and-kernel-details/

作者：sk 选题：lujun9972 译者：geekpi 校对：wxy

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

了解如何使用 Podman 在单独的用户空间运行容器。

Podman 是 libpod 库的一部分，使用户能够管理 pod、容器和容器镜像。在我的上一篇文章中，我写过将 Podman 作为一种更安全的运行容器的方式。在这里，我将解释如何使用 Podman 在单独的用户命名空间中运行容器。

作为分离容器的一个很棒的功能，我一直在思考 用户命名空间 user namespace ，它主要是由 Red Hat 的 Eric Biederman 开发的。用户命名空间允许你指定用于运行容器的用户标识符（UID）和组标识符（GID）映射。这意味着你可以在容器内以 UID 0 运行，在容器外以 UID 100000 运行。如果容器进程逃逸出了容器，内核会将它们视为以 UID 100000 运行。不仅如此，任何未映射到用户命名空间的 UID 所拥有的文件对象都将被视为 nobody 所拥有（UID 是 65534， 由 kernel.overflowuid 指定），并且不允许容器进程访问，除非该对象可由“其他人”访问（即世界可读/可写）。

如果你拥有一个权限为 660 的属主为“真实” root 的文件，而当用户命名空间中的容器进程尝试读取它时，会阻止它们访问它，并且会将该文件视为 nobody 所拥有。

示例

以下是它是如何工作的。首先，我在 root 拥有的系统中创建一个文件。

$ sudo bash -c "echo Test > /tmp/test"
$ sudo chmod 600 /tmp/test
$ sudo ls -l /tmp/test
-rw-------. 1 root root 5 Dec 17 16:40 /tmp/test

接下来，我将该文件卷挂载到一个使用用户命名空间映射 0:100000:5000 运行的容器中。

$ sudo podman run -ti -v /tmp/test:/tmp/test:Z --uidmap 0:100000:5000 fedora sh
# id
uid=0(root) gid=0(root) groups=0(root)
# ls -l /tmp/test
-rw-rw----. 1 nobody nobody 8 Nov 30 12:40 /tmp/test
# cat /tmp/test
cat: /tmp/test: Permission denied

上面的 --uidmap 设置告诉 Podman 在容器内映射一系列的 5000 个 UID，从容器外的 UID 100000 开始的范围（100000-104999）映射到容器内 UID 0 开始的范围（0-4999）。在容器内部，如果我的进程以 UID 1 运行，则它在主机上为 100001。

由于实际的 UID=0 未映射到容器中，因此 root 拥有的任何文件都将被视为 nobody 所拥有。即使容器内的进程具有 CAP_DAC_OVERRIDE 能力，也无法覆盖此种保护。DAC_OVERRIDE 能力使得 root 的进程能够读/写系统上的任何文件，即使进程不是 root 用户拥有的，也不是全局可读或可写的。

用户命名空间的功能与宿主机上的功能不同。它们是命名空间的功能。这意味着我的容器的 root 只在容器内具有功能 —— 实际上只有该范围内的 UID 映射到内用户命名空间。如果容器进程逃逸出了容器，则它将没有任何非映射到用户命名空间的 UID 之外的功能，这包括 UID=0。即使进程可能以某种方式进入另一个容器，如果容器使用不同范围的 UID，它们也不具备这些功能。

请注意，SELinux 和其他技术还限制了容器进程破开容器时会发生的情况。

使用 podman top 来显示用户名字空间

我们在 podman top 中添加了一些功能，允许你检查容器内运行的进程的用户名，并标识它们在宿主机上的真实 UID。

让我们首先使用我们的 UID 映射运行一个 sleep 容器。

$ sudo podman run --uidmap 0:100000:5000 -d fedora sleep 1000

现在运行 podman top：

$ sudo podman top --latest user huser
USER   HUSER
root   100000

$ ps -ef | grep sleep
100000   21821 21809  0 08:04 ?         00:00:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000

注意 podman top 报告用户进程在容器内以 root 身份运行，但在宿主机（HUSER）上以 UID 100000 运行。此外，ps 命令确认 sleep 过程以 UID 100000 运行。

现在让我们运行第二个容器，但这次我们将选择一个单独的 UID 映射，从 200000 开始。

$ sudo podman run --uidmap 0:200000:5000 -d fedora sleep 1000
$ sudo podman top --latest user huser
USER   HUSER
root   200000

$ ps -ef | grep sleep
100000   21821 21809  0 08:04 ?         00:00:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000
200000   23644 23632  1 08:08 ?         00:00:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000

请注意，podman top 报告第二个容器在容器内以 root 身份运行，但在宿主机上是 UID=200000。

另请参阅 ps 命令，它显示两个 sleep 进程都在运行：一个为 100000，另一个为 200000。

这意味着在单独的用户命名空间内运行容器可以在进程之间进行传统的 UID 分离，而这从一开始就是 Linux/Unix 的标准安全工具。

用户名字空间的问题

几年来，我一直主张用户命名空间应该作为每个人应该有的安全工具，但几乎没有人使用过。原因是没有任何文件系统支持，也没有一个 移动文件系统 shifting file system 。

在容器中，你希望在许多容器之间共享基本镜像。上面的每个示例中使用了 Fedora 基本镜像。Fedora 镜像中的大多数文件都由真实的 UID=0 拥有。如果我在此镜像上使用用户名称空间 0:100000:5000 运行容器，默认情况下它会将所有这些文件视为 nobody 所拥有，因此我们需要移动所有这些 UID 以匹配用户名称空间。多年来，我想要一个挂载选项来告诉内核重新映射这些文件 UID 以匹配用户命名空间。上游内核存储开发人员还在继续研究，在此功能上已经取得一些进展，但这是一个难题。

由于由 Nalin Dahyabhai 领导的团队开发的自动 chown 内置于容器/存储中，Podman 可以在同一镜像上使用不同的用户名称空间。当 Podman 使用容器/存储，并且 Podman 在新的用户命名空间中首次使用一个容器镜像时，容器/存储会 “chown”（如，更改所有权）镜像中的所有文件到用户命名空间中映射的 UID 并创建一个新镜像。可以把它想象成一个 fedora:0:100000:5000 镜像。

当 Podman 在具有相同 UID 映射的镜像上运行另一个容器时，它使用“预先 chown”的镜像。当我在0:200000:5000 上运行第二个容器时，容器/存储会创建第二个镜像，我们称之为 fedora:0:200000:5000。

请注意，如果你正在执行 podman build 或 podman commit 并将新创建的镜像推送到容器注册库，Podman 将使用容器/存储来反转该移动，并将推送所有文件属主变回真实 UID=0 的镜像。

这可能会导致在新的 UID 映射中创建容器时出现真正的减速，因为 chown 可能会很慢，具体取决于镜像中的文件数。此外，在普通的 OverlayFS 上，镜像中的每个文件都会被复制。普通的 Fedora 镜像最多可能需要 30 秒才能完成 chown 并启动容器。

幸运的是，Red Hat 内核存储团队（主要是 Vivek Goyal 和 Miklos Szeredi）在内核 4.19 中为 OverlayFS 添加了一项新功能。该功能称为“仅复制元数据”。如果使用 metacopy=on 选项来挂载层叠文件系统，则在更改文件属性时，它不会复制较低层的内容；内核会创建新的 inode，其中包含引用指向较低级别数据的属性。如果内容发生变化，它仍会复制内容。如果你想试用它，可以在 Red Hat Enterprise Linux 8 Beta 中使用此功能。

这意味着容器 chown 可能在两秒钟内发生，并且你不会倍增每个容器的存储空间。

这使得像 Podman 这样的工具在不同的用户命名空间中运行容器是可行的，大大提高了系统的安全性。

前瞻

我想向 Podman 添加一个新选项，比如 --userns=auto，它会为你运行的每个容器自动选择一个唯一的用户命名空间。这类似于 SELinux 与单独的多类别安全（MCS）标签一起使用的方式。如果设置环境变量 PODMAN_USERNS=auto，则甚至不需要设置该选项。

Podman 最终允许用户在不同的用户名称空间中运行容器。像 Buildah 和 CRI-O 这样的工具也可以利用用户命名空间。但是，对于 CRI-O，Kubernetes 需要了解哪个用户命名空间将运行容器引擎，上游正在开发这个功能。

在我的下一篇文章中，我将解释如何在用户命名空间中将 Podman 作为非 root 用户运行。

via: https://opensource.com/article/18/12/podman-and-user-namespaces

作者：Daniel J Walsh 选题：lujun9972 译者：wxy 校对：wxy

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

Xfce 是一个非常轻量的桌面环境，但它有一个缺点，它看起来有点老旧。但是你没有必要坚持默认外观。让我们看看你可以自定义 Xfce 的各种方法，来给它一个现代化的、漂亮的外观。

首先，Xfce 是最受欢迎的桌面环境之一。作为一个轻量级桌面环境，你可以在非常低的资源上运行 Xfce，并且它仍然能很好地工作。这是为什么很多轻量级 Linux 发行版默认使用 Xfce 的原因之一。

一些人甚至喜欢在高端设备上使用它，说明它的简单性、易用性和非资源依赖性是主要原因。

Xfce 自身很小，而且只提供你需要的东西。令人烦恼的一点是会令人觉得它的外观和感觉很老了。然而，你可以简单地自定义 Xfce 以使其看起来现代化和漂亮，但又不会像 Unity/GNOME 会话那样占用系统资源。

4 种方式来自定义 Xfce 桌面

让我们看看一些方法，我们可以通过这些方法改善你的 Xfce 桌面环境的外观和感觉。

默认 Xfce 桌面环境看起来有些像这样：

如你所见，默认 Xfce 桌面有点乏味。我们将使用主题、图标包以及更改默认 dock 来使它看起来新鲜和有点惊艳。

1. 在 Xfce 中更改主题

我们将做的第一件事是从 xfce-look.org 中找到一款主题。我最喜欢的 Xfce 主题是 XFCE-D-PRO。

你可以从这里下载主题，并提取到某处。

你可以复制提取出的这些主题文件到你的家目录中的 .theme 文件夹。如果该文件夹尚不存在，你可以创建一个，同样的道理，图标需要放在一个在家目录中的 .icons 文件夹。

打开 设置 > 外观 > 样式 来选择该主题，注销并重新登录以查看更改。默认的 Adwaita-dark 也是一个不错的主题。

你可以在 Xfce 上使用各种好的 GTK 主题。

2. 在 Xfce 中更改图标

Xfce-look.org 也提供你可以下载的图标主题，提取并放置图标到你的家目录中 .icons 目录。在你添加图标主题到 .icons 目录中后，转到 设置 > 外观 > 图标 来选择这个图标主题。

我已经安装 Moka 图标集 ，它看起来令人惊艳。

你也可以参考我们令人惊艳的图标主题列表。

可选: 通过 Synaptic 安装主题

如果你想避免手工搜索和复制文件，在你的系统中安装 Synaptic 软件包管理器。你可以通过网络来查找最佳的主题和图标集，使用 synaptic 软件包管理器，你可以搜索和安装主题。

sudo apt-get install synaptic

通过 Synaptic 搜索和安装主题/图标

打开 synaptic，并在搜索上单击。输入你期望的主题名，接下来，它将显示匹配主题的列表。勾选所有更改所需的附加依赖，并在应用上单击。这些操作将下载主题和安装主题。

在安装后，你可以打开外观选项来选择期望的主题。

在我看来，这不是在 Xfce 中安装主题的最佳方法。

3. 在 Xfce 中更改桌面背景

再强调一次，默认 Xfce 桌面背景也不错。但是你可以把桌面背景更改成与你的图标和主题相匹配的东西。

为在 Xfce 中更改桌面背景，在桌面上右击，并单击桌面设置。从文件夹选择中选择背景，并选择任意一个默认背景或自定义背景。

4. 在 Xfce 中更改 dock

默认 dock 也不错，恰如其分。但是，再强调一次，它看来有点平平淡淡。

不过，如果你想你的 dock 变得更好，并带有更多一点的自定义选项，你可以安装另一个 dock 。

Plank 是一个简单而轻量级的、高度可配置的 dock。

为安装 Plank ，使用下面的命令：

sudo apt-get install plank

如果 Plank 在默认存储库中没有，你可以从这个 PPA 中安装它。

sudo add-apt-repository ppa:ricotz/docky
sudo apt-get update
sudo apt-get install plank

在你使用 Plank 前，你应该通过右键单击移除默认的 dock，并在面板设置下，单击删除。

在完成后，转到 附件 > Plank 来启动 Plank dock 。

Plank 从你正在使用的图标主题中选取图标。因此，如果你更改图标主题，你也将在 dock 中看到相关的更改。

总结

XFCE 是一个轻量级、快速和高度可自定义的桌面环境。如果你的系统资源有限，它服务很好，并且你可以简单地自定义它来看起来更好。这是在应用这些步骤后，我的屏幕的外观。

这只是半个小时的努力成果，你可以使用不同的主题/图标自定义使它看起来更好。请随意在评论区分享你自定义的 XFCE 桌面屏幕，以及你正在使用的主题和图标组合。

via: https://itsfoss.com/customize-xfce/

作者：Ambarish Kumar 选题：lujun9972 译者：robsean 校对：wxy

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

如果你弄坏了你的 Ubuntu 系统，并尝试了很多方法来修复，你最终放弃并采取简单的方法：重新安装 Ubuntu。

我们一直遇到这样一种情况，重新安装 Linux 似乎比找出问题并解决来得更好。排查 Linux 故障能教你很多，但你不会总是花费更多时间来修复损坏的系统。

据我所知，Ubuntu 中没有像 Windows 那样的系统恢复分区。那么，问题出现了：如何重新安装 Ubuntu？让我告诉你如何重新安装 Ubuntu。

警告！

磁盘分区始终是一项危险的任务。我强烈建议你在外部磁盘上备份数据。

如何重新安装 Ubuntu Linux

以下是重新安装 Ubuntu 的步骤。

步骤 1：创建一个 live USB

首先，在网站上下载 Ubuntu。你可以下载任何需要的 Ubuntu 版本。

• 下载 Ubuntu

获得 ISO 镜像后，就可以创建 live USB 了。如果 Ubuntu 系统仍然可以使用，那么可以使用 Ubuntu 提供的启动盘创建工具创建它。

如果无法使用你的 Ubuntu，那么你可以使用其他系统。你可以参考这篇文章来学习如何在 Windows 中创建 Ubuntu 的 live USB。

步骤 2：重新安装 Ubuntu

有了 Ubuntu 的 live USB 之后将其插入 USB 端口。重新启动系统。在启动时，按下 F2/F10/F12 之类的键进入 BIOS 设置，并确保已设置 “Boot from Removable Devices/USB”。保存并退出 BIOS。这将启动进入 live USB。

进入 live USB 后，选择安装 Ubuntu。你将看到选择语言和键盘布局这些常用选项。你还可以选择下载更新等。

现在是重要的步骤。你应该看到一个“ 安装类型 Installation Type ”页面。你在屏幕上看到的内容在很大程度上取决于 Ubuntu 如何处理系统上的磁盘分区和安装的操作系统。

在此步骤中仔细阅读选项及它的细节。注意每个选项的说明。屏幕上的选项可能在不同的系统中看上去不同。

在这里，它发现我的系统上安装了 Ubuntu 18.04.2 和 Windows，它给了我一些选项。

第一个选项是擦除 Ubuntu 18.04.2 并重新安装它。它告诉我它将删除我的个人数据，但它没有说删除所有操作系统（即 Windows）。

如果你非常幸运或处于单一启动模式，你可能会看到一个“ 重新安装 Ubuntu Reinstall Ubuntu ”的选项。此选项将保留现有数据，甚至尝试保留已安装的软件。如果你看到这个选项，那么就用它吧。

双启动系统注意

如果你是双启动 Ubuntu 和 Windows，并且在重新安装中，你的 Ubuntu 系统看不到 Windows，你必须选择 “Something else” 选项并从那里安装 Ubuntu。我已经在在双启动下安装 Linux 的过程这篇文章中说明了。

对我来说，没有重新安装并保留数据的选项，因此我选择了“ 擦除 Ubuntu 并重新安装 Erase Ubuntu and reinstall ”。该选项即使在 Windows 的双启动模式下，也将重新安装 Ubuntu。

我建议为 / 和 /home 使用单独分区就是为了重新安装。这样，即使重新安装 Linux，也可以保证 /home 分区中的数据安全。我已在此视频中演示过：

选择重新安装 Ubuntu 后，剩下就是单击下一步。选择你的位置、创建用户账户。

以上完成后，你就完成重装 Ubuntu 了。

在本教程中，我假设你已经知道我说的东西，因为你之前已经安装过 Ubuntu。如果需要澄清任何一个步骤，请随时在评论栏询问。

via: https://itsfoss.com/reinstall-ubuntu/

作者：Abhishek Prakash 选题：lujun9972 译者：geekpi 校对： wxy

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

Podman 使用传统的 fork/exec 模型（相对于客户端/服务器模型）来运行容器。

在进入本文的主要主题 Podman 和容器之前，我需要了解一点 Linux 审计功能的技术。

什么是审计？

Linux 内核有一个有趣的安全功能，叫做审计。它允许管理员在系统上监视安全事件，并将它们记录到audit.log 中，该文件可以本地存储或远程存储在另一台机器上，以防止黑客试图掩盖他的踪迹。

/etc/shadow 文件是一个经常要监控的安全文件，因为向其添加记录可能允许攻击者获得对系统的访问权限。管理员想知道是否有任何进程修改了该文件，你可以通过执行以下命令来执行此操作：

# auditctl -w /etc/shadow

现在让我们看看当我修改了 /etc/shadow 文件会发生什么：

# touch /etc/shadow 
# ausearch -f /etc/shadow -i -ts recent

type=PROCTITLE msg=audit(10/10/2018 09:46:03.042:4108) : proctitle=touch /etc/shadow type=SYSCALL msg=audit(10/10/2018 09:46:03.042:4108) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffdb17f6704 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=2712 pid=3727 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=touch exe=/usr/bin/touch subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)`

审计记录中有很多信息，但我重点注意到它记录了 root 修改了 /etc/shadow 文件，并且该进程的审计 UID（auid）的所有者是 dwalsh。

内核修改了这个文件了么？

跟踪登录 UID

登录 UID（loginuid），存储在 /proc/self/loginuid 中，它是系统上每个进程的 proc 结构的一部分。该字段只能设置一次；设置后，内核将不允许任何进程重置它。

当我登录系统时，登录程序会为我的登录过程设置 loginuid 字段。

我（dwalsh）的 UID 是 3267。

$ cat /proc/self/loginuid
3267

现在，即使我变成了 root，我的登录 UID 仍将保持不变。

$ sudo cat /proc/self/loginuid
3267

请注意，从初始登录过程 fork 并 exec 的每个进程都会自动继承 loginuid。这就是内核知道登录的人是 dwalsh 的方式。

容器

现在让我们来看看容器。

sudo podman run fedora cat /proc/self/loginuid
3267

甚至容器进程也保留了我的 loginuid。 现在让我们用 Docker 试试。

sudo docker run fedora cat /proc/self/loginuid 
4294967295

为什么不一样？

Podman 对于容器使用传统的 fork/exec 模型，因此容器进程是 Podman 进程的后代。Docker 使用客户端/服务器模型。我执行的 docker 命令是 Docker 客户端工具，它通过客户端/服务器操作与 Docker 守护进程通信。然后 Docker 守护程序创建容器并处理 stdin/stdout 与 Docker 客户端工具的通信。

进程的默认 loginuid（在设置 loginuid 之前）是 4294967295（LCTT 译注：2 ³² - 1）。由于容器是 Docker 守护程序的后代，而 Docker 守护程序是 init 系统的子代，所以，我们看到 systemd、Docker 守护程序和容器进程全部具有相同的 loginuid：4294967295，审计系统视其为未设置审计 UID。

cat /proc/1/loginuid 
4294967295

怎么会被滥用？

让我们来看看如果 Docker 启动的容器进程修改 /etc/shadow 文件会发生什么。

$ sudo docker run --privileged -v /:/host fedora touch /host/etc/shadow 
$ sudo ausearch -f /etc/shadow -i type=PROCTITLE msg=audit(10/10/2018 10:27:20.055:4569) : proctitle=/usr/bin/coreutils --coreutils-prog-shebang=touch /usr/bin/touch /host/etc/shadow type=SYSCALL msg=audit(10/10/2018 10:27:20.055:4569) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffdb6973f50 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=11863 pid=11882 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=touch exe=/usr/bin/coreutils subj=system_u:system_r:spc_t:s0 key=(null)

在 Docker 情形中，auid 是未设置的（4294967295）；这意味着安全人员可能知道有进程修改了 /etc/shadow 文件但身份丢失了。

如果该攻击者随后删除了 Docker 容器，那么在系统上谁修改 /etc/shadow 文件将没有任何跟踪信息。

现在让我们看看相同的场景在 Podman 下的情况。

$ sudo podman run --privileged -v /:/host fedora touch /host/etc/shadow 
$ sudo ausearch -f /etc/shadow -i type=PROCTITLE msg=audit(10/10/2018 10:23:41.659:4530) : proctitle=/usr/bin/coreutils --coreutils-prog-shebang=touch /usr/bin/touch /host/etc/shadow type=SYSCALL msg=audit(10/10/2018 10:23:41.659:4530) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7fffdffd0f34 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=11671 pid=11683 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=3 comm=touch exe=/usr/bin/coreutils subj=unconfined_u:system_r:spc_t:s0 key=(null)

由于它使用传统的 fork/exec 方式，因此 Podman 正确记录了所有内容。

这只是观察 /etc/shadow 文件的一个简单示例，但审计系统对于观察系统上的进程非常有用。使用 fork/exec 容器运行时（而不是客户端/服务器容器运行时）来启动容器允许你通过审计日志记录保持更好的安全性。

最后的想法

在启动容器时，与客户端/服务器模型相比，fork/exec 模型还有许多其他不错的功能。例如，systemd 功能包括：

• SD_NOTIFY：如果将 Podman 命令放入 systemd 单元文件中，容器进程可以通过 Podman 返回通知，表明服务已准备好接收任务。这是在客户端/服务器模式下无法完成的事情。
• 套接字激活：你可以将连接的套接字从 systemd 传递到 Podman，并传递到容器进程以便使用它们。这在客户端/服务器模型中是不可能的。

在我看来，其最好的功能是作为非 root 用户运行 Podman 和容器。这意味着你永远不会在宿主机上授予用户 root 权限，而在客户端/服务器模型中（如 Docker 使用的），你必须打开以 root 身份运行的特权守护程序的套接字来启动容器。在那里，你将受到守护程序中实现的安全机制与宿主机操作系统中实现的安全机制的支配 —— 这是一个危险的主张。

via: https://opensource.com/article/18/10/podman-more-secure-way-run-containers

作者：Daniel J Walsh 选题：lujun9972 译者：wxy 校对：wxy

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