document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-04 22:00:34 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'LCTT/master'

Browse Source
This commit is contained in:
Xingyu.Wang 2018-12-22 18:09:23 +08:00
commit 55c2b8f57b
4 changed files with 193 additions and 191 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
translated/tech/20181115 3 best practices for continuous integration and deployment.md → published/20181115 3 best practices for continuous integration and deployment.md
View File

@ -1,31 +1,33 @@
持续集成与部署的3个最佳实践
持续集成与部署的 3 个最佳实践
======
了解自动化，使用 Git 存储库以及参数化 Jenkins 管道。
> 了解自动化，使用 Git 存储库以及参数化 Jenkins 管道。
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/innovation_lightbulb_gears_devops_ansible.png?itok=TSbmp3_M)
本文涵盖了三个关键主题：自动化 CI/CD 配置、使用 Git 存储库处理常见的 CI/CD 工件、参数化 Jenkins 管道。
### 术语
首先，我们定义一些术语。**CI/CD** 是允许团队快速自动化测试、打包、部署其应用程序的实践。它通常通过利用名为 **[Jenkins][1]** 的服务器来实现，该服务器充当 CI/CD 协调器。Jenkins 侦听特定输入（通常是代码签入后的 Git hook），并在触发时启动管道。
首先，我们定义一些术语。**CI/CD** 是允许团队快速自动化测试、打包、部署其应用程序的实践。它通常通过利用名为 [Jenkins][1] 的服务器来实现，该服务器充当 CI/CD 协调器。Jenkins 侦听特定输入（通常是代码签入后的 Git 挂钩），并在触发时启动一个管道。
**pipeline** 由开发和/或运营团队编写的代码组成，这些代码指导 Jenkins 在 CI/CD 过程中采取哪些操作。这个流水线通常类似于“构建我的代码，然后测试我的代码，如果这些测试通过，则把我的应用程序部署到下一个最高环境（通常是开发、测试或生产环境）”。组织通常具有更复杂的流水线，并入了诸如工件存储库和代码分析器之类的工具，但是这提供了一个高级示例。
<ruby>管道<rt>pipeline</rt></ruby> 由开发和/或运营团队编写的代码组成，这些代码指导 Jenkins 在 CI/CD 过程中采取哪些操作。这个流水线通常类似于“构建我的代码，然后测试我的代码，如果这些测试通过，则把我的应用程序部署到下一个最高环境（通常是开发、测试或生产环境）”。组织通常具有更复杂的管道，并入了诸如工件存储库和代码分析器之类的工具，这里提供了一个高级示例。
现在我们了解了关键术语，让我们深入研究一些最佳实践。
### 1\. 自动化是关键
### 1、自动化是关键
要在 PaaS 上运行 CI/CD，需要在集群上配置适当的基础设施。在这个例子中，我将使用 [OpenShift][2]。
"Hello, World" 的实现很容易实现。简单地运行 **oc new-app jenkins- <persistent/ephemeral>** 和 voilà, 你已经准备好运行 Jenkins 服务器了。然而，在企业中的使用要复杂得多。除了 Jenkins 服务器之外，管理员通常还需要部署代码分析工具（如 SonarQube）和构件库（如 Nexus）。然后，它们必须创建管道来执行 CI/CD 和 Jenkins 从服务器，以减少主服务器的负载。这些实体中的大多数都由 OpenShift 资源支持，需要创建这些资源来部署所需的 CI/CD 基础设施。
“Hello, World” 的实现很容易实现。简单地运行 `oc new-app jenkins-<persistent/ephemeral>`，然后，你就有了一个已经就绪的运行中的 Jenkins 服务器了。然而，在企业中的使用要复杂得多。除了 Jenkins 服务器之外，管理员通常还需要部署代码分析工具（如 SonarQube）和工件库（如 Nexus）。然后，它们必须创建管道来执行 CI/CD 和 Jenkins 从服务器，以减少主服务器的负载。这些实体中的大多数都由 OpenShift 资源支持，需要创建这些资源来部署所需的 CI/CD 基础设施。
最后，部署 CI/CD 组件所需要的手动步骤可能是需要被重复的，并且你可能不想成为执行那些重复步骤的人。为了确保结果能够像以前一样快速、无错误和准确地产生，应该在创建基础设施的方式中结合自动化方法。这可以是一个 Ansible 剧本、一个 Bash 脚本，或者任何您希望自动化 CI/CD 基础设施部署的其他方式。我已经使用 [Ansible][3] 和 [OpenShift-Applier][4] 角色来自动化我的实现。您可能会发现这些工具很有价值，或者您可能会发现其他一些对您和组织更有效的工具。无论哪种方式，您都将发现自动化显著地减少了重新创建 CI/CD 组件所需的工作量。
最后，部署 CI/CD 组件所需要的手动步骤可能是需要重复进行的，而且你可能不想成为执行那些重复步骤的人。为了确保结果能够像以前一样快速、无错误和准确地产生，应该在创建基础设施的方式中结合自动化方法。这可以是一个 Ansible 剧本、一个 Bash 脚本，或者任何您希望自动化 CI/CD 基础设施部署的其它方式。我已经使用 [Ansible][3] 和 [OpenShift-Applier][4] 角色来自动化我的实现。您可能会发现这些工具很有价值，或者您可能会发现其他一些对您和组织更有效的工具。无论哪种方式，您都将发现自动化显著地减少了重新创建 CI/CD 组件所需的工作量。
#### 配置Jenkins主服务器
#### 配置 Jenkins 主服务器
除了一般的“自动化”之外，我想单独介绍一下 Jenkins 主服务器，并讨论管理员如何利用 OpenShift 来自动化配置 Jenkins。来自 [Red Hat Container Catalog][5] 的 Jenkins 映像已经安装了 [OpenShift-Sync plugin][6]。在 [视频][7] 中，我们将讨论如何使用这个插件来创建 Jenkins 管道和从设备。
除了一般的“自动化”之外，我想单独介绍一下 Jenkins 主服务器，并讨论管理员如何利用 OpenShift 来自动化配置 Jenkins。来自 [Red Hat Container Catalog][5] 的 Jenkins 镜像已经安装了 [OpenShift-Sync plugin][6]。在 [该视频][7] 中，我们将讨论如何使用这个插件来创建 Jenkins 管道和从设备。
要创建 Jenkins 流水线，请创建一个类似于下面的 OpenShift BuildConfig：
要创建 Jenkins 管道，请创建一个类似于下面的 OpenShift BuildConfig：
```
apiVersion: v1
@ -43,7 +45,7 @@ spec:  
    type: JenkinsPipeline
```
OpenShift-Sync 插件将注意到已经创建了带有 **jenkinsPipelineStrategy** 策略的 BuildConfig，并将其转换为 Jenkins 管道，从 Git 源指定的 Jenkins 文件中提取。也可以使用内联 Jenkinsfile，而不是从 Git 存储库中提取。有关更多信息，请参阅[文档][8]。
OpenShift-Sync 插件将注意到已经创建了带有 `jenkinsPipelineStrategy` 策略的 BuildConfig，并将其转换为 Jenkins 管道，从 Git 源指定的 Jenkinsfile 中提取。也可以使用内联 Jenkinsfile，而不是从 Git 存储库中提取。有关更多信息，请参阅[文档][8]。
要创建 Jenkins 从站，请创建一个 OpenShift ImageStream，它从以下定义开始：
@ -55,12 +57,12 @@ metadata:
    slave-label: jenkins-slave
    labels:
      role: jenkins-slave
…
...
```
注意在这个 ImageStream 中定义的元数据。OpenShift-Sync 插件将把带有标签 **role: jenkins-slave** 的任何ImageStream 转换为 Jenkins 从站。Jenkins 从站将以 **slave-label** 注释中的值命名。
注意在这个 ImageStream 中定义的元数据。OpenShift-Sync 插件将把带有标签 `role: jenkins-slave` 的任何 ImageStream 转换为 Jenkins 从站。Jenkins 从站将以 `slave-label` 注释中的值命名。
ImageStreams 对于简单的 Jenkins 从属配置工作得很好，但是一些团队会发现有必要配置一些细节详情，比如资源限制、准备就绪和活动性探测，以及实例帽。这就是 ConfigMap 发挥作用的地方：
ImageStreams 对于简单的 Jenkins 从属配置工作得很好，但是一些团队会发现有必要配置一些细节详情，比如资源限制、准备就绪和活动性探测，以及实例上限。这就是 ConfigMap 发挥作用的地方：
```
apiVersion: v1
@ -74,21 +76,21 @@ data:
    <Kubernetes pod template>
```
注意，仍然需要角色：jenkins-slave 标签来将 ConfigMap 转换为 Jenkins slave。Kubernetes pod 模板由一长段 XML 组成，它将根据组织的喜好配置每个细节。要查看此 XML，以及有关将 ImageStreams 和 ConfigMaps 转换为 Jenkins 从属的更多信息，请参阅[文档][9]。
注意，仍然需要角色：`jenkins-slave` 标签来将 ConfigMap 转换为 Jenkins 从站。Kubernetes pod 模板由一长段 XML 组成，它将根据组织的喜好配置每个细节。要查看此 XML，以及有关将 ImageStreams 和 ConfigMaps 转换为 Jenkins 从站的更多信息，请参阅[文档][9]。
请注意上面所示的三个示例，其中没有一个操作需要管理员对 Jenkins 控制台进行手动更改。通过使用 OpenShift 资源，可以简单的自动化方式配置 Jenkins。
### 2\. 分享就是关心
### 2、分享就是关爱
第二个最佳实践是维护一个公共 CI/CD 工件的 Git 存储库。主要思想是防止团队重新发明轮子。假设您的团队需要执行到 OpenShift 环境的蓝色/绿色部署，作为管道 CD 阶段的一部分。负责编写流水线的团队成员可能不是 OpenShift 专家，也不可能具有从头开始编写此功能的能力。幸运的是，有人已经编写了一个将此功能合并到一个公共 CI/CD 存储库中的函数，因此您的团队可以使用该函数而不是花时间编写一个函数。
第二个最佳实践是维护一个公共 CI/CD 工件的 Git 存储库。主要思想是防止团队重新发明轮子。假设您的团队需要执行到 OpenShift 环境的蓝/绿部署，作为管道 CD 阶段的一部分。负责编写管道的团队成员可能不是 OpenShift 专家，也不可能具有从头开始编写此功能的能力。幸运的是，有人已经编写了一个将此功能合并到一个公共 CI/CD 存储库中的函数，因此您的团队可以使用该函数而不是花时间编写一个函数。
为了更进一步，您的组织可能决定维护整个管道。您可能会发现团队正在编写具有相似功能的流水线。对于那些团队来说，使用来自公共存储库的参数化管道要比从头开始编写自己的管道更有效。
为了更进一步，您的组织可能决定维护整个管道。您可能会发现团队正在编写具有相似功能的管道。对于那些团队来说，使用来自公共存储库的参数化管道要比从头开始编写自己的管道更有效。
### 3\. 少即是多
### 3、少即是多
正如我在前一节中提到的，第三个也是最后一个最佳实践是参数化您的 CI/CD 管道。参数化将防止过多的管道，使您的 CI/CD 系统更容易维护。假设我有多个区域可以部署应用程序。如果没有参数化，我需要为每个区域设置单独的管道。
要参数化作为 OpenShift 构建配置编写的管道，请将 **env** 节添加到配置：
要参数化一个作为 OpenShift 构建配置编写的管道，请将 `env` 节添加到配置：
```
...
@ -103,9 +105,9 @@ spec:
    type: JenkinsPipeline
```
使用此配置，我可以传递 **REGION** 参数管道以将我的应用程序部署到指定区域。
使用此配置，我可以传递 `REGION` 参数给管道以将我的应用程序部署到指定区域。
这有一个[视频][7]提供了一个更实质性的情况，其中参数化是必须的。一些组织决定把他们的 CI/CD 管道分割成单独的 CI 和 CD 管道，通常是因为在部署之前有一些审批过程。假设我有四个映像和三个不同的环境要部署。如果没有参数化，我需要12个 CD 管道来允许所有部署可能性。这会很快失去控制。为了使 CD 流水线的维护更容易，组织会发现将映像和环境参数化以便允许一个流水线执行多个流水线的工作会更好。
这有一个[视频][7]提供了一个更实质性的情况，其中参数化是必须的。一些组织决定把他们的 CI/CD 管道分割成单独的 CI 和 CD 管道，通常是因为在部署之前有一些审批过程。假设我有四个镜像和三个不同的环境要部署。如果没有参数化，我需要 12 个 CD 管道来允许所有部署可能性。这会很快失去控制。为了使 CD 流水线的维护更容易，组织会发现将镜像和环境参数化以便允许一个流水线执行多个流水线的工作会更好。
### 总结
@ -120,7 +122,7 @@ via: https://opensource.com/article/18/11/best-practices-cicd
作者：[Austin Dewey][a]
选题：[lujun9972][b]
译者：[ChiZelin](https://github.com/ChiZelin)
校对：[校对者ID](https://github.com/校对者ID)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

168
sources/tech/20180307 Protecting Code Integrity with PGP - Part 4- Moving Your Master Key to Offline Storage.md
View File

@ -1,168 +0,0 @@
Translating by qhwdw
Protecting Code Integrity with PGP — Part 4: Moving Your Master Key to Offline Storage
======
![](https://www.linux.com/sites/lcom/files/styles/rendered_file/public/industry-1920.jpg?itok=gI3QraS8)
In this tutorial series, we're providing practical guidelines for using PGP. You can catch up on previous articles here:
[Part 1: Basic Concepts and Tools][1]
[Part 2: Generating Your Master Key][2]
[Part 3: Generating PGP Subkeys][3]
Here in part 4, we continue the series with a look at how and why to move your master key from your home directory to offline storage. Let's get started.
### Checklist
* Prepare encrypted detachable storage (ESSENTIAL)
* Back up your GnuPG directory (ESSENTIAL)
* Remove the master key from your home directory (NICE)
* Remove the revocation certificate from your home directory (NICE)
#### Considerations
Why would you want to remove your master [C] key from your home directory? This is generally done to prevent your master key from being stolen or accidentally leaked. Private keys are tasty targets for malicious actors -- we know this from several successful malware attacks that scanned users' home directories and uploaded any private key content found there.
It would be very damaging for any developer to have their PGP keys stolen -- in the Free Software world, this is often tantamount to identity theft. Removing private keys from your home directory helps protect you from such events.
##### Back up your GnuPG directory
**!!!Do not skip this step!!!**
It is important to have a readily available backup of your PGP keys should you need to recover them (this is different from the disaster-level preparedness we did with paperkey).
##### Prepare detachable encrypted storage
Start by getting a small USB "thumb" drive (preferably two!) that you will use for backup purposes. You will first need to encrypt them:
For the encryption passphrase, you can use the same one as on your master key.
##### Back up your GnuPG directory
Once the encryption process is over, re-insert the USB drive and make sure it gets properly mounted. Find out the full mount point of the device, for example by running the mount command (under Linux, external media usually gets mounted under /media/disk, under Mac it's /Volumes).
Once you know the full mount path, copy your entire GnuPG directory there:
```
$ cp -rp ~/.gnupg [/media/disk/name]/gnupg-backup
```
(Note: If you get any Operation not supported on socket errors, those are benign and you can ignore them.)
You should now test to make sure everything still works:
```
$ gpg --homedir=[/media/disk/name]/gnupg-backup --list-key [fpr]
```
If you don't get any errors, then you should be good to go. Unmount the USB drive and distinctly label it, so you don't blow it away next time you need to use a random USB drive. Then, put in a safe place -- but not too far away, because you'll need to use it every now and again for things like editing identities, adding or revoking subkeys, or signing other people's keys.
##### Remove the master key
The files in our home directory are not as well protected as we like to think. They can be leaked or stolen via many different means:
* By accident when making quick homedir copies to set up a new workstation
* By systems administrator negligence or malice
* Via poorly secured backups
* Via malware in desktop apps (browsers, pdf viewers, etc)
* Via coercion when crossing international borders
Protecting your key with a good passphrase greatly helps reduce the risk of any of the above, but passphrases can be discovered via keyloggers, shoulder-surfing, or any number of other means. For this reason, the recommended setup is to remove your master key from your home directory and store it on offline storage.
###### Removing your master key
Please see the previous section and make sure you have backed up your GnuPG directory in its entirety. What we are about to do will render your key useless if you do not have a usable backup!
First, identify the keygrip of your master key:
```
$ gpg --with-keygrip --list-key [fpr]
```
The output will be something like this:
```
pub rsa4096 2017-12-06 [C] [expires: 2019-12-06]
111122223333444455556666AAAABBBBCCCCDDDD
Keygrip = AAAA999988887777666655554444333322221111
uid [ultimate] Alice Engineer <alice@example.org>
uid [ultimate] Alice Engineer <allie@example.net>
sub rsa2048 2017-12-06 [E]
Keygrip = BBBB999988887777666655554444333322221111
sub rsa2048 2017-12-06 [S]
Keygrip = CCCC999988887777666655554444333322221111
```
Find the keygrip entry that is beneath the pub line (right under the master key fingerprint). This will correspond directly to a file in your home .gnupg directory:
```
$ cd ~/.gnupg/private-keys-v1.d
$ ls
AAAA999988887777666655554444333322221111.key
BBBB999988887777666655554444333322221111.key
CCCC999988887777666655554444333322221111.key
```
All you have to do is simply remove the .key file that corresponds to the master keygrip:
```
$ cd ~/.gnupg/private-keys-v1.d
$ rm AAAA999988887777666655554444333322221111.key
```
Now, if you issue the --list-secret-keys command, it will show that the master key is missing (the # indicates it is not available):
```
$ gpg --list-secret-keys
sec# rsa4096 2017-12-06 [C] [expires: 2019-12-06]
111122223333444455556666AAAABBBBCCCCDDDD
uid [ultimate] Alice Engineer <alice@example.org>
uid [ultimate] Alice Engineer <allie@example.net>
ssb rsa2048 2017-12-06 [E]
ssb rsa2048 2017-12-06 [S]
```
##### Remove the revocation certificate
Another file you should remove (but keep in backups) is the revocation certificate that was automatically created with your master key. A revocation certificate allows someone to permanently mark your key as revoked, meaning it can no longer be used or trusted for any purpose. You would normally use it to revoke a key that, for some reason, you can no longer control -- for example, if you had lost the key passphrase.
Just as with the master key, if a revocation certificate leaks into malicious hands, it can be used to destroy your developer digital identity, so it's better to remove it from your home directory.
```
cd ~/.gnupg/openpgp-revocs.d
rm [fpr].rev
```
Next time, you'll learn how to secure your subkeys as well. Stay tuned.
Learn more about Linux through the free ["Introduction to Linux" ][4]course from The Linux Foundation and edX.
--------------------------------------------------------------------------------
via: https://www.linux.com/blog/learn/pgp/2018/3/protecting-code-integrity-pgp-part-4-moving-your-master-key-offline-storage
作者：[Konstantin Ryabitsev][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://www.linux.com/users/mricon
[1]:https://www.linux.com/blog/learn/2018/2/protecting-code-integrity-pgp-part-1-basic-pgp-concepts-and-tools
[2]:https://www.linux.com/blog/learn/pgp/2018/2/protecting-code-integrity-pgp-part-2-generating-and-protecting-your-master-pgp-key
[3]:https://www.linux.com/blog/learn/pgp/2018/2/protecting-code-integrity-pgp-part-3-generating-pgp-subkeys
[4]:https://training.linuxfoundation.org/linux-courses/system-administration-training/introduction-to-linux

1
sources/tech/20180314 Protecting Code Integrity with PGP - Part 5- Moving Subkeys to a Hardware Device.md
View File

@ -1,3 +1,4 @@
Translating by qhwdw
Protecting Code Integrity with PGP — Part 5: Moving Subkeys to a Hardware Device
======

167
translated/tech/20180307 Protecting Code Integrity with PGP - Part 4- Moving Your Master Key to Offline Storage.md Normal file
View File

@ -0,0 +1,167 @@
用 PGP 保护代码完整性（四）：将主密钥移到离线存储中
======
![](https://www.linux.com/sites/lcom/files/styles/rendered_file/public/industry-1920.jpg?itok=gI3QraS8)
在本系列教程中，我们为使用 PGP 提供了一个实用指南。你可以从下面的链接中查看前面的文章：
[第一部分：基本概念和工具][1]
[第二部分：生成你的主密钥][2]
[第三部分：生成 PGP 子密钥][3]
这是本系列教程的第四部分，我们继续本教程，我们将谈一谈如何及为什么要将主密钥从你的 Home 目录移到离线存储中。现在开始我们的教程。
### 清单
* 准备一个加密的可移除的存储（必要）
* 备份你的 GnuPG 目录（必要）
* 从你的 Home 目录中删除主密钥（推荐）
* 从你的 Home 目录中删除吊销证书（推荐）
#### Considerations
为什么要从你的 Home 目录中删除你的主密钥 [C] ？这样做的主要原因是防止你的主密钥失窃或意外泄露。对于心怀不轨的人来说，私钥对他们具有很大的诱惑力 —— 我们知道有几个恶意软件成功地实现了扫描用户的 Home 目录并将发现的任何私钥内容上传。
对于任何开发者来说，私钥失窃是非常危险的事情 —— 在自由软件的世界中，这无疑是身份证明失窃。从你的 Home 目录中删除私钥将帮你防范这类事件的发生。
##### 备份你的 GnuPG 目录
**!!!绝对不要跳过这一步!!!**
备份你的 PGP 密钥将让你在需要的时候很容易地恢复它们，这很重要！（这与我们做的使用 paperkey 的灾难级备份是不一样的）。
##### 准备可移除的加密存储
我们从取得一个（最好是两个）小型的 USB “拇指“ 驱动器（可加密 U 盘）开始，我们将用它来做备份。你首先需要去加密它们：
加密密码可以使用与主密钥相同的密码。
##### 备份你的 GnuPG 目录
加密过程结束之后，重新插入 USB 驱动器并确保它能够正常挂载。你可以通过运行 `mount` 命令去找到设备挂载点的完全路径。（在 Linux 下，外置介质一般挂载在 /media/disk 下，Mac 一般在它的 /Volumes 下）
你知道了挂载点的全路径后，将你的整个 GnuPG 的目录复制进去：
```
$ cp -rp ~/.gnupg [/media/disk/name]/gnupg-backup
```
（注意：如果出现任何套接字不支持的错误，没有关系，直接忽略它们。）
现在，用如下的命令去测试一下，确保它们能够正常地工作：
```
$ gpg --homedir=[/media/disk/name]/gnupg-backup --list-key [fpr]
```
如果没有出现任何错误，说明一切正常。弹出这个 USB 驱动器并给它粘上一个明确的标签，以便于你下次需要它时能够很快找到它。接着，将它放到一个安全的 —— 但不要太远 —— 的地方，因为从现在起，你需要偶尔使用它来做一些像编辑身份信息、添加或吊销子证书、或签署其它人的密钥这样的事情。
##### 删除主密钥
我们 Home 目录中的文件并没有像我们所想像的那样受到保护。它们可能会通过许多不同的方式被泄露或失窃：
* 通过快速复制来配置一个新工作站时的偶尔事故
* 通过系统管理员的疏忽或恶意操作
* 通过安全性欠佳的备份
* 通过桌面应用中的恶意软件（浏览器、pdf 查看器等等）
* 通过跨境胁迫
使用一个很好的密码来保护你的密钥是降低上述风险的一个很好方法，但是密码能够通过键盘记录器、背后窥视、或其它方式被发现。基于以上原因，我们建议去配置一个从你的 Home 目录上可移除的主密钥，将它保存在一个离线存储中。
###### 删除主密钥
**请查看前面的节，确保你有完整的你的 GnuPG 目录的一个备份。如果你没有一个可用的备份，下面所做的操作将会使你的主密钥失效！！！**
首先，识别你的主密钥的 keygrip：
```
$ gpg --with-keygrip --list-key [fpr]
```
它的输出应该像下面这样：
```
pub rsa4096 2017-12-06 [C] [expires: 2019-12-06]
111122223333444455556666AAAABBBBCCCCDDDD
Keygrip = AAAA999988887777666655554444333322221111
uid [ultimate] Alice Engineer <alice@example.org>
uid [ultimate] Alice Engineer <allie@example.net>
sub rsa2048 2017-12-06 [E]
Keygrip = BBBB999988887777666655554444333322221111
sub rsa2048 2017-12-06 [S]
Keygrip = CCCC999988887777666655554444333322221111
```
找到 pub 行下方的 keygrip 条目（就在主密钥指纹的下方）。它与你的 Home 目录下 `.gnupg` 目录下的一个文件是一致的：
```
$ cd ~/.gnupg/private-keys-v1.d
$ ls
AAAA999988887777666655554444333322221111.key
BBBB999988887777666655554444333322221111.key
CCCC999988887777666655554444333322221111.key
```
现在你做的全部操作就是简单地删除与主密钥 keygrip 一致的 `.key` 文件：
```
$ cd ~/.gnupg/private-keys-v1.d
$ rm AAAA999988887777666655554444333322221111.key
```
现在，如果运行 --list-secret-keys 命令将出现问题，它将显示主密钥丢失（# 表示不可用）：
```
$ gpg --list-secret-keys
sec# rsa4096 2017-12-06 [C] [expires: 2019-12-06]
111122223333444455556666AAAABBBBCCCCDDDD
uid [ultimate] Alice Engineer <alice@example.org>
uid [ultimate] Alice Engineer <allie@example.net>
ssb rsa2048 2017-12-06 [E]
ssb rsa2048 2017-12-06 [S]
```
##### 删除吊销证书
你应该去删除的另一个文件是吊销证书（**删除之前，确保你的备份中有它**），它是使用你的主密钥自动创建的。吊销证书允许一些人去永久标记你的证书为吊销状态，这意味着它无论在任何用途中将不再被使用或信任。一般是使用它来吊销由于某些原因不再受控的一个密钥 —— 比如，你丢失了密钥密码。
与使用主密钥一样，如果一个吊销证书泄露到恶意者手中，他们能够使用它去破坏你的开发者数字身份，因此，最好是从你的 Home 目录中删除它。
```
cd ~/.gnupg/openpgp-revocs.d
rm [fpr].rev
```
在下一篇文章中，你将学习如何保护你的子密钥。敬请期待。
从来自 Linux 基金会和 edX 的免费课程 [“Linux 入门" ][4] 中学习更多 Linux 知识。
--------------------------------------------------------------------------------
via: https://www.linux.com/blog/learn/pgp/2018/3/protecting-code-integrity-pgp-part-4-moving-your-master-key-offline-storage
作者：[Konstantin Ryabitsev][a]
译者：[qhwdw](https://github.com/qhwdw)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://www.linux.com/users/mricon
[1]:https://www.linux.com/blog/learn/2018/2/protecting-code-integrity-pgp-part-1-basic-pgp-concepts-and-tools
[2]:https://www.linux.com/blog/learn/pgp/2018/2/protecting-code-integrity-pgp-part-2-generating-and-protecting-your-master-pgp-key
[3]:https://www.linux.com/blog/learn/pgp/2018/2/protecting-code-integrity-pgp-part-3-generating-pgp-subkeys
[4]:https://training.linuxfoundation.org/linux-courses/system-administration-training/introduction-to-linux