mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-24 02:20:09 +08:00
zyk
GitHub
commit
99a04b6c15
@ -0,0 +1,130 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-11200-1.html)
|
||||
[#]: subject: (How to detect automatically generated emails)
|
||||
[#]: via: (https://arp242.net/weblog/autoreply.html)
|
||||
[#]: author: (Martin Tournoij https://arp242.net/)
|
||||
|
||||
如何检测自动生成的电子邮件
|
||||
======
|
||||
|
||||
|
||||
|
||||
当你用电子邮件系统发送自动回复时，你需要注意不要向自动生成的电子邮件发送回复。最好的情况下，你将获得无用的投递失败消息。更可能的是，你会得到一个无限的电子邮件循环和一个混乱的世界。
|
||||
|
||||
事实证明，可靠地检测自动生成的电子邮件并不总是那么容易。以下是基于为此编写的检测器并使用它扫描大约 100,000 封电子邮件（大量的个人存档和公司存档）的观察结果。
|
||||
|
||||
### Auto-submitted 信头
|
||||
|
||||
由 [RFC 3834][1] 定义。
|
||||
|
||||
这是表示你的邮件是自动回复的“官方”标准。如果存在 `Auto-Submitted` 信头，并且其值不是 `no`，你应该**不**发送回复。
|
||||
|
||||
### X-Auto-Response-Suppress 信头
|
||||
|
||||
[由微软][2]定义。
|
||||
|
||||
此信头由微软 Exchange、Outlook 和其他一些产品使用。许多新闻订阅等都设定了这个。如果 `X-Auto-Response-Suppress` 包含 `DR`（“抑制投递报告”）、`AutoReply`（“禁止 OOF 通知以外的自动回复消息”）或 `All`，你应该**不**发送回复。
|
||||
|
||||
### List-Id 和 List-Unsubscribe 信头
|
||||
|
||||
由 [RFC 2919][3] 定义。
|
||||
|
||||
你通常不希望给邮件列表或新闻订阅发送自动回复。几乎所有的邮件列表和大多数新闻订阅都至少设置了其中一个信头。如果存在这些信头中的任何一个，你应该**不**发送回复。这个信头的值不重要。
|
||||
|
||||
### Feedback-ID 信头
|
||||
|
||||
[由谷歌][4]定义。
|
||||
|
||||
Gmail 使用此信头识别邮件是否是新闻订阅，并使用它为这些新闻订阅的所有者生成统计信息或报告。如果此信头存在，你应该**不**发送回复。这个信头的值不重要。
|
||||
|
||||
### 非标准方式
|
||||
|
||||
上述方法定义明确（即使有些是非标准的）。不幸的是，有些电子邮件系统不使用它们中的任何一个 :-( 这里有一些额外的措施。
|
||||
|
||||
#### Precedence 信头
|
||||
|
||||
在 [RFC 2076][5] 中没有真正定义，不鼓励使用它（但通常会遇到此信头）。
|
||||
|
||||
请注意，不建议检查是否存在此信头，因为某些邮件使用 `normal` 和其他一些（少见的）值（尽管这不常见）。
|
||||
|
||||
我的建议是如果其值不区分大小写地匹配 `bulk`、`auto_reply` 或 `list`，则**不**发送回复。
|
||||
|
||||
#### 其他不常见的信头
|
||||
|
||||
这是我遇到的另外的一些（不常见的）信头。如果设置了其中一个，我建议**不**发送自动回复。大多数邮件也设置了上述信头之一，但有些没有（这并不常见）。
|
||||
|
||||
* `X-MSFBL`：无法真正找到定义（Microsoft 信头？），但我只有自动生成的邮件带有此信头。
|
||||
* `X-Loop`：在任何地方都没有真正定义过，有点罕见，但有时有。它通常设置为不应该收到电子邮件的地址，但也会遇到 `X-Loop: yes`。
|
||||
* `X-Autoreply`：相当罕见，并且似乎总是具有 `yes` 的值。
|
||||
|
||||
#### Email 地址
|
||||
|
||||
检查 `From` 或 `Reply-To` 信头是否包含 `noreply`、`no-reply` 或 `no_reply`（正则表达式：`^no.?reply@`）。
|
||||
|
||||
#### 只有 HTML 部分
|
||||
|
||||
如果电子邮件只有 HTML 部分，而没有文本部分，则表明这是一个自动生成的邮件或新闻订阅。几乎所有邮件客户端都设置了文本部分。
|
||||
|
||||
#### 投递失败消息
|
||||
|
||||
许多传递失败消息并不能真正表明它们是失败的。一些检查方法：
|
||||
|
||||
* `From` 包含 `mailer-daemon` 或 `Mail Delivery Subsystem`
|
||||
|
||||
#### 特定的邮件库特征
|
||||
|
||||
许多邮件类库留下了某种痕迹，大多数常规邮件客户端使用自己的数据覆盖它。检查这个似乎工作得相当可靠。
|
||||
|
||||
* `X-Mailer: Microsoft CDO for Windows 2000`：由某些微软软件设置；我只能在自动生成的邮件中找到它。是的，在 2015 年它仍然在使用。
|
||||
* `Message-ID` 信头包含 `.JavaMail.`：我发现了一些（5 个 50k 大小的）常规消息，但不是很多；绝大多数（数千封）邮件是新闻订阅、订单确认等。
|
||||
* `^X-Mailer` 以 `PHP` 开头。这应该会同时看到 `X-Mailer: PHP/5.5.0` 和 `X-Mailer: PHPmailer XXX XXX`。与 “JavaMail” 相同。
|
||||
* 出现了 `X-Library`；似乎只有 [Indy][6] 设定了这个。
|
||||
* `X-Mailer` 以 `wdcollect` 开头。由一些 Plesk 邮件设置。
|
||||
* `X-Mailer` 以 `MIME-tools` 开头。
|
||||
|
||||
### 最后的预防措施：限制回复的数量
|
||||
|
||||
即使遵循上述所有建议，你仍可能会遇到一个避开所有这些检测的电子邮件程序。这可能非常危险，因为电子邮件系统只是“如果有电子邮件那么发送”，就有可能导致无限的电子邮件循环。
|
||||
|
||||
出于这个原因，我建议你记录你自动发送的电子邮件，并将此速率限制为在几分钟内最多几封电子邮件。这将打破循环链条。
|
||||
|
||||
我们使用每五分钟一封电子邮件的设置，但没这么严格的设置可能也会运作良好。
|
||||
|
||||
### 你需要为自动回复设置什么信头
|
||||
|
||||
具体细节取决于你发送的邮件类型。这是我们用于自动回复邮件的内容：
|
||||
|
||||
```
|
||||
Auto-Submitted: auto-replied
|
||||
X-Auto-Response-Suppress: All
|
||||
Precedence: auto_reply
|
||||
```
|
||||
|
||||
### 反馈
|
||||
|
||||
你可以发送电子邮件至 [martin@arp242.net][7] 或 [创建 GitHub 议题][8]以提交反馈、问题等。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://arp242.net/weblog/autoreply.html
|
||||
|
||||
作者：[Martin Tournoij][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://arp242.net/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: http://tools.ietf.org/html/rfc3834
|
||||
[2]: https://msdn.microsoft.com/en-us/library/ee219609(v=EXCHG.80).aspx
|
||||
[3]: https://tools.ietf.org/html/rfc2919)
|
||||
[4]: https://support.google.com/mail/answer/6254652?hl=en
|
||||
[5]: http://www.faqs.org/rfcs/rfc2076.html
|
||||
[6]: http://www.indyproject.org/index.en.aspx
|
||||
[7]: mailto:martin@arp242.net
|
||||
[8]: https://github.com/Carpetsmoker/arp242.net/issues/new
|
||||
@ -0,0 +1,228 @@
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: "wxy"
|
||||
[#]: reviewer: "wxy"
|
||||
[#]: publisher: "wxy"
|
||||
[#]: url: "https://linux.cn/article-11198-1.html"
|
||||
[#]: subject: "How To Parse And Pretty Print JSON With Linux Commandline Tools"
|
||||
[#]: via: "https://www.ostechnix.com/how-to-parse-and-pretty-print-json-with-linux-commandline-tools/"
|
||||
[#]: author: "EDITOR https://www.ostechnix.com/author/editor/"
|
||||
|
||||
如何用 Linux 命令行工具解析和格式化输出 JSON
|
||||
======
|
||||
|
||||
|
||||
|
||||
JSON 是一种轻量级且与语言无关的数据存储格式，易于与大多数编程语言集成，也易于人类理解 —— 当然，如果格式正确的话。JSON 这个词代表 **J**ava **S**cript **O**bject **N**otation，虽然它以 JavaScript 开头，而且主要用于在服务器和浏览器之间交换数据，但现在正在用于许多领域，包括嵌入式系统。在这里，我们将使用 Linux 上的命令行工具解析并格式化打印 JSON。它对于在 shell 脚本中处理大型 JSON 数据或在 shell 脚本中处理 JSON 数据非常有用。
|
||||
|
||||
### 什么是格式化输出？
|
||||
|
||||
JSON 数据的结构更具人性化。但是在大多数情况下，JSON 数据会存储在一行中，甚至没有行结束字符。
|
||||
|
||||
显然，这对于手动阅读和编辑不太方便。
|
||||
|
||||
这是<ruby>格式化输出<rt>pretty print</rt></ruby>就很有用。这个该名称不言自明：重新格式化 JSON 文本，使人们读起来更清晰。这被称为 **JSON 格式化输出**。
|
||||
|
||||
### 用 Linux 命令行工具解析和格式化输出 JSON
|
||||
|
||||
可以使用命令行文本处理器解析 JSON 数据，例如 `awk`、`sed` 和 `gerp`。实际上 `JSON.awk` 是一个来做这个的 awk 脚本。但是，也有一些专用工具可用于同一目的。
|
||||
|
||||
1. `jq` 或 `jshon`，shell 下的 JSON 解析器，它们都非常有用。
|
||||
2. Shell 脚本，如 `JSON.sh` 或 `jsonv.sh`，用于在 bash、zsh 或 dash shell 中解析JSON。
|
||||
3. `JSON.awk`，JSON 解析器 awk 脚本。
|
||||
4. 像 `json.tool` 这样的 Python 模块。
|
||||
5. `undercore-cli`，基于 Node.js 和 javascript。
|
||||
|
||||
在本教程中，我只关注 `jq`，这是一个 shell 下的非常强大的 JSON 解析器，具有高级过滤和脚本编程功能。
|
||||
|
||||
### JSON 格式化输出
|
||||
|
||||
JSON 数据可能放在一行上使人难以解读，因此为了使其具有一定的可读性，JSON 格式化输出就可用于此目的的。
|
||||
|
||||
**示例：**来自 `jsonip.com` 的数据，使用 `curl` 或 `wget` 工具获得 JSON 格式的外部 IP 地址，如下所示。
|
||||
|
||||
```
|
||||
$ wget -cq http://jsonip.com/ -O -
|
||||
```
|
||||
|
||||
实际数据看起来类似这样：
|
||||
|
||||
```
|
||||
{"ip":"111.222.333.444","about":"/about","Pro!":"http://getjsonip.com"}
|
||||
```
|
||||
|
||||
现在使用 `jq` 格式化输出它：
|
||||
|
||||
```
|
||||
$ wget -cq http://jsonip.com/ -O - | jq '.'
|
||||
```
|
||||
|
||||
通过 `jq` 过滤了该结果之后，它应该看起来类似这样：
|
||||
|
||||
```
|
||||
{
|
||||
"ip": "111.222.333.444",
|
||||
"about": "/about",
|
||||
"Pro!": "http://getjsonip.com"
|
||||
}
|
||||
```
|
||||
|
||||
同样也可以通过 Python `json.tool` 模块做到。示例如下：
|
||||
|
||||
```
|
||||
$ cat anything.json | python -m json.tool
|
||||
```
|
||||
|
||||
这种基于 Python 的解决方案对于大多数用户来说应该没问题，但是如果没有预安装或无法安装 Python 则不行，比如在嵌入式系统上。
|
||||
|
||||
然而，`json.tool` Python 模块具有明显的优势，它是跨平台的。因此，你可以在 Windows、Linux 或 Mac OS 上无缝使用它。
|
||||
|
||||
### 如何用 jq 解析 JSON
|
||||
|
||||
首先，你需要安装 `jq`，它已被大多数 GNU/Linux 发行版选中，并使用各自的软件包安装程序命令进行安装。
|
||||
|
||||
在 Arch Linux 上：
|
||||
|
||||
```
|
||||
$ sudo pacman -S jq
|
||||
```
|
||||
|
||||
在 Debian、Ubuntu、Linux Mint 上：
|
||||
|
||||
```
|
||||
$ sudo apt-get install jq
|
||||
```
|
||||
|
||||
在 Fedora 上：
|
||||
|
||||
```
|
||||
$ sudo dnf install jq
|
||||
```
|
||||
|
||||
在 openSUSE 上：
|
||||
|
||||
```
|
||||
$ sudo zypper install jq
|
||||
```
|
||||
|
||||
对于其它操作系统或平台参见[官方的安装指导][1]。
|
||||
|
||||
#### jq 的基本过滤和标识符功能
|
||||
|
||||
`jq` 可以从 `STDIN` 或文件中读取 JSON 数据。你可以根据情况使用。
|
||||
|
||||
单个符号 `.` 是最基本的过滤器。这些过滤器也称为**对象标识符-索引**。`jq` 使用单个 `.` 过滤器基本上相当将输入的 JSON 文件格式化输出。
|
||||
|
||||
- **单引号**：不必始终使用单引号。但是如果你在一行中组合几个过滤器，那么你必须使用它们。
|
||||
- **双引号**：你必须用两个双引号括起任何特殊字符，如 `@`、`＃`、`$`，例如 `jq .foo.”@bar”`。
|
||||
- **原始数据打印**：不管出于任何原因，如果你只需要最终解析的数据（不包含在双引号内），请使用带有 `-r` 标志的 `jq` 命令，如下所示：`jq -r .foo.bar`。
|
||||
|
||||
#### 解析特定数据
|
||||
|
||||
要过滤出 JSON 的特定部分，你需要了解格式化输出的 JSON 文件的数据层次结构。
|
||||
|
||||
来自维基百科的 JSON 数据示例：
|
||||
|
||||
```
|
||||
{
|
||||
"firstName": "John",
|
||||
"lastName": "Smith",
|
||||
"age": 25,
|
||||
"address": {
|
||||
"streetAddress": "21 2nd Street",
|
||||
"city": "New York",
|
||||
"state": "NY",
|
||||
"postalCode": "10021"
|
||||
},
|
||||
"phoneNumber": [
|
||||
{
|
||||
"type": "home",
|
||||
"number": "212 555-1234"
|
||||
},
|
||||
{
|
||||
"type": "fax",
|
||||
"number": "646 555-4567"
|
||||
}
|
||||
],
|
||||
"gender": {
|
||||
"type": "male"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
我将在本教程中将此 JSON 数据用作示例，将其保存为 `sample.json`。
|
||||
|
||||
假设我想从 `sample.json` 文件中过滤出地址。所以命令应该是这样的：
|
||||
|
||||
```
|
||||
$ jq .address sample.json
|
||||
```
|
||||
|
||||
示例输出：
|
||||
|
||||
```
|
||||
{
|
||||
"streetAddress": "21 2nd Street",
|
||||
"city": "New York",
|
||||
"state": "NY",
|
||||
"postalCode": "10021"
|
||||
}
|
||||
```
|
||||
|
||||
再次，我想要邮政编码，然后我要添加另一个**对象标识符-索引**，即另一个过滤器。
|
||||
|
||||
```
|
||||
$ cat sample.json | jq .address.postalCode
|
||||
```
|
||||
|
||||
另请注意，**过滤器区分大小写**，并且你必须使用完全相同的字符串来获取有意义的输出，否则就是 null。
|
||||
|
||||
#### 从 JSON 数组中解析元素
|
||||
|
||||
JSON 数组的元素包含在方括号内，这无疑是非常通用的。
|
||||
|
||||
要解析数组中的元素，你必须使用 `[]` 标识符以及其他对象标识符索引。
|
||||
|
||||
在此示例 JSON 数据中，电话号码存储在数组中，要从此数组中获取所有内容，你只需使用括号，像这个示例：
|
||||
|
||||
```
|
||||
$ jq .phoneNumber[] sample.json
|
||||
```
|
||||
|
||||
假设你只想要数组的第一个元素，然后使用从 `0` 开始的数组对象编号，对于第一个项目，使用 `[0]`，对于下一个项目，它应该每步增加 1。
|
||||
|
||||
```
|
||||
$ jq .phoneNumber[0] sample.json
|
||||
```
|
||||
|
||||
#### 脚本编程示例
|
||||
|
||||
假设我只想要家庭电话，而不是整个 JSON 数组数据。这就是用 `jq` 命令脚本编写的方便之处。
|
||||
|
||||
```
|
||||
$ cat sample.json | jq -r '.phoneNumber[] | select(.type == "home") | .number'
|
||||
```
|
||||
|
||||
首先，我将一个过滤器的结果传递给另一个，然后使用 `select` 属性选择特定类型的数据，再次将结果传递给另一个过滤器。
|
||||
|
||||
解释每种类型的 `jq` 过滤器和脚本编程超出了本教程的范围和目的。强烈建议你阅读 `jq` 手册，以便更好地理解下面的内容。
|
||||
|
||||
资源：
|
||||
|
||||
- https://stedolan.github.io/jq/manual/
|
||||
- http://www.compciv.org/recipes/cli/jq-for-parsing-json/
|
||||
- https://lzone.de/cheat-sheet/jq
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/how-to-parse-and-pretty-print-json-with-linux-commandline-tools/
|
||||
|
||||
作者：[ostechnix][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.ostechnix.com/author/editor/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://stedolan.github.io/jq/download/
|
||||
@ -1,8 +1,8 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-11199-1.html)
|
||||
[#]: subject: (Bash Script to Send a Mail When a New User Account is Created in System)
|
||||
[#]: via: (https://www.2daygeek.com/linux-bash-script-to-monitor-user-creation-send-email/)
|
||||
[#]: author: (Magesh Maruthamuthu https://www.2daygeek.com/author/magesh/)
|
||||
@ -10,74 +10,55 @@
|
||||
在系统创建新用户时发送邮件的 Bash 脚本
|
||||
======
|
||||
|
||||
目前市场上有许多开源监测工具可用于监控 Linux 系统的性能。
|
||||
|
||||
|
||||
当系统到达指定的阈值时，它将发送邮件提醒。
|
||||
目前市场上有许多开源监测工具可用于监控 Linux 系统的性能。当系统到达指定的阈值时，它将发送邮件提醒。
|
||||
|
||||
它会监控 CPU 利用率、内存利用率、交换内存利用率、磁盘空间利用率等所有内容。
|
||||
|
||||
但我不认为他们可以选择监控新用户创建活动，并发送提醒。
|
||||
它会监控 CPU 利用率、内存利用率、交换内存利用率、磁盘空间利用率等所有内容。但我不认为它们可以选择监控新用户创建活动，并发送提醒。
|
||||
|
||||
如果没有，这并不重要，因为我们可以编写自己的 bash 脚本来实现这一点。
|
||||
|
||||
我们过去写了许多有用的 shell 脚本。如果要查看它们，请点击以下链接。
|
||||
|
||||
* **[如何使用 shell 脚本自动化执行日常任务？][1]**
|
||||
* [如何使用 shell 脚本自动化执行日常任务？][1]
|
||||
|
||||
这个脚本做了什么？它监测 `/var/log/secure` 文件，并在系统创建新帐户时提醒管理员。
|
||||
|
||||
我们不会经常运行此脚本，因为创建用户不经常发生。但是，我打算一天运行一次这个脚本。因此，我们可以获得有关用户创建的综合报告。
|
||||
|
||||
脚本做了什么？它监测 **`/var/log/secure`** 文件，并在系统创建新帐户时提醒管理员。
|
||||
|
||||
我们不会经常运行此脚本，因为创建用户不经常发生。但是，我打算一天运行一次这个脚本。
|
||||
|
||||
因此，我们可以获得有关用户创建的综合报告。
|
||||
|
||||
如果在昨天的 “/var/log/secure” 中找到了 useradd 字符串，那么该脚本将向指定的邮箱发送邮件提醒，其中包含了新用户的详细信息。
|
||||
如果在昨天的 `/var/log/secure` 中找到了 “useradd” 字符串，那么该脚本将向指定的邮箱发送邮件提醒，其中包含了新用户的详细信息。
|
||||
|
||||
**注意：**你需要更改邮箱而不是使用我们的邮箱。
|
||||
|
||||
```
|
||||
# vi /opt/scripts/new-user.sh
|
||||
```
|
||||
|
||||
```
|
||||
#!/bin/bash
|
||||
|
||||
#Set the variable which equal to zero
|
||||
prev_count=0
|
||||
|
||||
count=$(grep -i "`date --date='yesterday' '+%b %e'`" /var/log/secure | egrep -wi 'useradd' | wc -l)
|
||||
|
||||
if [ "$prev_count" -lt "$count" ] ; then
|
||||
|
||||
# Send a mail to given email id when errors found in log
|
||||
|
||||
SUBJECT="ATTENTION: New User Account is created on server : `date --date='yesterday' '+%b %e'`"
|
||||
|
||||
# This is a temp file, which is created to store the email message.
|
||||
|
||||
MESSAGE="/tmp/new-user-logs.txt"
|
||||
|
||||
TO="[email protected]"
|
||||
|
||||
echo "Hostname: `hostname`" >> $MESSAGE
|
||||
|
||||
echo -e "\n" >> $MESSAGE
|
||||
|
||||
echo "The New User Details are below." >> $MESSAGE
|
||||
|
||||
echo "+------------------------------+" >> $MESSAGE
|
||||
|
||||
grep -i "`date --date='yesterday' '+%b %e'`" /var/log/secure | egrep -wi 'useradd' | grep -v 'failed adding'| awk '{print $4,$8}' | uniq | sed 's/,/ /' >> $MESSAGE
|
||||
|
||||
echo "+------------------------------+" >> $MESSAGE
|
||||
|
||||
mail -s "$SUBJECT" "$TO" < $MESSAGE
|
||||
|
||||
rm $MESSAGE
|
||||
|
||||
# Send a mail to given email id when errors found in log
|
||||
SUBJECT="ATTENTION: New User Account is created on server : `date --date='yesterday' '+%b %e'`"
|
||||
# This is a temp file, which is created to store the email message.
|
||||
MESSAGE="/tmp/new-user-logs.txt"
|
||||
TO="2daygeek@gmail.com"
|
||||
echo "Hostname: `hostname`" >> $MESSAGE
|
||||
echo -e "\n" >> $MESSAGE
|
||||
echo "The New User Details are below." >> $MESSAGE
|
||||
echo "+------------------------------+" >> $MESSAGE
|
||||
grep -i "`date --date='yesterday' '+%b %e'`" /var/log/secure | egrep -wi 'useradd' | grep -v 'failed adding'| awk '{print $4,$8}' | uniq | sed 's/,/ /' >> $MESSAGE
|
||||
echo "+------------------------------+" >> $MESSAGE
|
||||
mail -s "$SUBJECT" "$TO" < $MESSAGE
|
||||
rm $MESSAGE
|
||||
fi
|
||||
```
|
||||
|
||||
给 **`new-user.sh`** 添加可执行权限。
|
||||
给 `new-user.sh` 添加可执行权限。
|
||||
|
||||
```
|
||||
$ chmod +x /opt/scripts/new-user.sh
|
||||
@ -114,7 +95,7 @@ via: https://www.2daygeek.com/linux-bash-script-to-monitor-user-creation-send-em
|
||||
作者：[Magesh Maruthamuthu][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,178 +0,0 @@
|
||||
0x996 is translating
|
||||
IT disaster recovery: Sysadmins vs. natural disasters | HPE
|
||||
======
|
||||
|
||||
|
||||
|
||||
Businesses need to keep going even when faced with torrential flooding or earthquakes. Sysadmins who lived through Katrina, Sandy, and other disasters share real-world advice for anyone responsible for IT during an emergency.
|
||||
|
||||
In terms of natural disasters, 2017 has been one heck of a year. Hurricanes Harvey, Irma, and Maria brought destruction to Houston, Puerto Rico, Florida, and the Caribbean. On top of that, wildfires burned out homes and businesses in the West.
|
||||
|
||||
It'd be easy to respond with yet another finger-wagging article about [preparing for disasters][1]--and surely it's all good advice--but that doesn't help a network administrator cope with the soggy mess. Most of those well-meant suggestions also assume that the powers that be are cheerfully willing to invest money in implementing them.
|
||||
|
||||
We're a little more interested in the real world. Instead, let's put that bad news to some good use.
|
||||
|
||||
Case in point: One result of a natural disaster is that the boss may suddenly be willing to find budget for disaster recovery planning. As a New York area sysadmin puts it, "The [greatest benefit I found from Hurricane Sandy][2] is our client's interest in investing back into IT, so hopefully you will welcome bigger budgets as well."
|
||||
|
||||
Don't expect that willingness to last long, though. Any sysadmin who'd like to suggest infrastructure improvements is urged to make hay while the sun shines. As another Sandy-survivor IT specialist ruefully remarks, "[Initial interest in IT spending lasted the calendar year for us][3]. By the following year, any plans that hadn't already been put in the works got put on the back burner due to 'budgetary constraints,' and then completely forgotten about by around 6 months later."
|
||||
|
||||
It can help to remind management of the cold hard facts before they forget that bad natural disasters can happen to good companies. According to the Institute for Business & Home Safety, [25 percent of businesses that close after a natural disaster never reopen][4]. FEMA thinks that's optimistic. By its measure, "[40 percent of small businesses never reopen their doors][5] following a disaster."
|
||||
|
||||
If you're a sysadmin, you can help save your business. Here are some of survivors' best ideas based on what they've learned from the past few natural disasters.
|
||||
|
||||
### Have a plan
|
||||
|
||||
When the lights flicker and the wind howls like a locomotive, it's time to put your business continuity and disaster recovery plans into operation.
|
||||
|
||||
Too many sysadmins report that neither were in place when the storms came. That's not surprising. In 2014, the [Disaster Recovery Preparedness Council][6] found that [73 percent of surveyed businesses worldwide didn't have adequate disaster recovery plans][7].
|
||||
|
||||
"Adequate" is a key word. As a sysadmin on Reddit wrote in 2016, "[Our disaster plan is a disaster.][8] All our data is backed up to a storage area network [SAN] about 30 miles from here. We have no hardware to get it back online or have even our core servers up and running within a few days. We're a $4 billion a year company that won't spend a few $100K for proper equipment. Or even some servers at a data center. Our executive team said, 'Meh what are the odds of anything happening' when the hardware proposal was brought up."
|
||||
|
||||
Another on the same thread put it more succinctly: "Currently my DR plan is to cry in a dark damp corner and hope nobody cared about anything that was lost."
|
||||
|
||||
Get the report from 451 Research - Datacenter Modernization: Trends and Challenges
|
||||
|
||||
[Transform with Hybrid IT][9]
|
||||
|
||||
If you're crying, let's hope you aren't crying alone. Any disaster plan, even one devised by the IT department, has to ascertain that [you can communicate with humans][10], as sysadmin Jim Thompson learned during Katrina: "Make sure you have a plan to communicate with people. During a serious regional disaster, you will not be able to call anyone with a phone in the affected area code."
|
||||
|
||||
One option that may appeal to the technically minded: [ham radio][11]. That [made a difference in Puerto Rico][12].
|
||||
|
||||
### Make a wish list
|
||||
|
||||
The first step is recognizing the problem. "Many companies are not actually interested in disaster recovery, or they address it reluctantly," says [Joshua Brusse][13], a chief architect at [Micro Focus][14]. "Viewing disaster recovery as an aspect of business continuity is a different perspective. All companies deal with business continuity, so disaster recovery should be considered as part of that."
|
||||
|
||||
Ensuring that there's an adequate disaster recovery and business continuity plan in place requires the IT department to document its needs. That's true even if--or particularly when--you don't get your way. As one sysadmin remarks, "I like to have a 'thought dump' location where any and all plans/ideas/improvements can be just dumped in with no limitations or restrictions. [This] is [especially helpful for when you propose a change][15], it gets shot down, and six months later that situation you warned about came up." Now you have everything prepared and can start the discussion: "As we discussed back in April…"
|
||||
|
||||
So, what can you do when your executive team responds to the business continuity plan with "Meh what are the odds of anything happening?" Shockingly poor judgement as that is, one sysadmin suggests it's also completely normal behavior for the executive layer. In situations this dire, experienced sysadmins say document the events. Be clear that you told the executives what needed to be done and that [they refused to do so][16]. "The general idea is to have a paper trail long enough for them to hang themselves," the sysadmin adds.
|
||||
|
||||
If that doesn't work, the experience of bringing back a flooded data center will serve you well in [a new job search][17].
|
||||
|
||||
### Protect the physical infrastructure
|
||||
|
||||
"[Our office is an old decrepit building][18]," reported one sysadmin after Harvey hammered Houston. "We went into the building blind and the infrastructure in place was terrible. We literally just finished the last of the drops we needed in that building and now it's all under water."
|
||||
|
||||
Nonetheless, if you want the data center to keep running--or to get back up and working after a storm--you need to ensure the facility can stand up to not only the kind of disasters expected in your area but the unexpected ones as well. One reason Sandy was devastating is that the New York area wasn't prepped for that sort of weather system. A sysadmin in San Francisco knows why it's important to ensure the company's servers are in a building that can withstand a magnitude 7 earthquake. A business in St. Louis knows how to respond to tornadoes. But you should prepare for every eventuality: a tornado in California, an earthquake in Missouri, or [a zombie apocalypse][19] (which also gives you justification for a chainsaw in the IT budget).
|
||||
|
||||
In Houston's case, [most data centers stayed up][20] and running because they were built to withstand storms and floods. [Data Foundry][21]'s chief technology officer, Edward Henigin, says of one of its data centers, "Houston 2 is a purpose-built facility designed to withstand Category 5 hurricane wind speeds. This site has not lost utility power, and we have not had to transition to our backup generators."
|
||||
|
||||
That's the good news. The bad news is, as superstorm Sandy showed in 2012, if your [data center isn't ready to handle flooding][22], you're in for a world of trouble. Customers of one failed data center, [Datagram][23], included high-profile sites Gawker, Gizmodo, and Buzzfeed.
|
||||
|
||||
Of course, sometimes there's nothing you can do. As one San Juan, Puerto Rico, sysadmin sadly wrote when Irma came through, "Generator took a dump. Server room running on batteries but no [air conditioning]. [Bye bye servers][24]." The sysadmin couldn't fail over to disaster recovery because the MPLS (Multiprotocol Label Switching) line was also down: "Fun day."
|
||||
|
||||
To sum up, IT professionals need to know their area, know their risks, and place their servers in data centers that can handle the local conditions.
|
||||
|
||||
### An argument for the cloud
|
||||
|
||||
The best way to avoid an IT data center failure when a storm rolls through is to make sure the backup data center is elsewhere. That requires sensible decision-making in locating them. Your backup data center should not be in a region that can be affected by the same natural disaster; place your resources in more than one availability zone. Think backup and primary along the same fault line in an earthquake or vulnerable to flooding from linked water sources.
|
||||
|
||||
Some sysadmins [use the cloud for redundancy][25]. For example, Microsoft Azure storage is always replicated to ensure durability and high availability. Depending on the options you choose, Azure replication copies your data, either within the same data center or to a second data center. Most public clouds offer similar automatic backup services to help ensure data stays safe no matter what happens to your local data center--unless your cloud provider is in the same storm path.
|
||||
|
||||
Expensive? Yes. As expensive as being down for a day or two? No.
|
||||
|
||||
Don't trust the public cloud? Consider a colocation (colo) service. With colo, you still own your hardware and run your own applications, but the hardware can be miles away from trouble. For instance, during Harvey, one company "virtually" moved all its resources from Houston to its colo in Austin, Texas. But those local data centers and colocation sites need to be ready to handle disasters; it's one of the criteria you should use in choosing them. For example, a Seattle sysadmin looking for colocation space considered, "It was all about their earthquake and drought protection (overbuilt foundations and water trucks to feed the chillers)."
|
||||
|
||||
### When the lights go out
|
||||
|
||||
The most [common cause of declared disaster is power failures][26], as Forrester Research analyst Rachel Dines reported in a survey for [Disaster Recovery Journal][27]. While you can work against those in ordinary circumstances, hurricanes, fires, and floods test the equipment past its limits.
|
||||
|
||||
One sysadmin's tongue-in-cheek plan? "Turn off what you can before the UPS dies, let crash what you can't. Then, [drink until power comes back on][28]."
|
||||
|
||||
A more serious plan driven by IT staff in the wake of 2016's Delta and Southwest outages was for a managed service provider to [deploy uninterruptible power supplies][29] to its clients: "On the critical pieces, we use a combination of SNMP signalling and PowerChute Network Shutdown (PCNS) clients to shut things down in the event of a power failure. Bringing things back up, well... that depends on the client. Some are automatic, and some require manual intervention."
|
||||
|
||||
Another approach is to support the data center with utility power from two substations. For example, the [Seattle Westin Building data cente][30]r has multiple 13.4-kilovolt utility feeds, diverse power substations, and multiple 480-volt three-phase transformer vaults.
|
||||
|
||||
Serious power failure prevention systems are not "one size fits all" units. Sysadmins should requisition a [custom-designed diesel generator for the data center][31]. Besides being tuned for your specific needs, generators must be capable of jumping to full speed in moments and accept full-power loads without impacting the load performance.
|
||||
|
||||
These generators must also be protected. For example, putting your generators on the ground floor in a flood plain is not a smart idea. The data centers on Broad Street in New York had fits during Superstorm Sandy because the backup generators' fuel tanks were in the basement--and they were flooded out. While a ["bucket brigade" relaying 5-gallon buckets of diesel fuel up 17 flights of stairs to the generator][32] kept [Peer 1 Hosting][33] in business, this is not a viable business continuity plan.
|
||||
|
||||
As most data center professionals know, if you have time--say, a hurricane is a day away--make sure your generator is working, fully fueled up, and is ready to kick on when the power lines get cut. Of course, you should have been testing your generator every month anyway. You have been doing that? Right? Right!
|
||||
|
||||
### Testing your confidence in backups
|
||||
|
||||
Ordinary users almost never make backups, and fewer still check to make sure their backups are actually any good. Sysadmins know better.
|
||||
|
||||
Some [IT departments are looking into moving their backups to the cloud][34]. But some sysadmins aren't sold on it yet--for good reason. One recently reported, "After [five solid days of restoring [400 GB of] data from Amazon Glacier][35], I owe Amazon nearly $200 in data transfer fees and [I] still have an inconsistent restore state and [am] missing 100 GB of my files."
|
||||
|
||||
As a result, some sysadmins still prefer tape backup. Tape is certainly not fashionable, but as operating system guru Andrew S. Tanenbaum says, "[Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway][36]."
|
||||
|
||||
These days, tape can handle 10 terabytes per tape; there are experiments underway that take tape up to 200 TB. Technologies such as the [Linear Tape File System][37] enable you to read tape data as if it were just another network drive.
|
||||
|
||||
Yet for many, tape is the [option of absolute last resort][38]. That's fine, because backup should have plenty of options. In this case, says one sysadmin, "we would have to fail with: [Windows] server level VSS [Volume Shadow Storage] snapshots, SAN level volume snapshots, and SAN level offsite archived snapshot copies. But if, hypothetically, something happened that nuked our VM, the SAN, and the backup SAN, we could still get the tapes back and recover the data."
|
||||
|
||||
When trouble is coming your way, use replication tools such as [Veeam][39], which create a virtual machine replica of your servers. If there's a failure, the replicas are automatically spun up. No fuss, no muss, as one sysadmin says in the popular sysadmin post, "[I love you Veeam.][40]"
|
||||
|
||||
### Network? What network?
|
||||
|
||||
Of course, no cloud, no colo, and no remote data center helps you if staff can't reach their services. You don't need a natural disaster to justify redundant Internet connections. All it takes is a backhoe cable cut or severed fiber lines to give you a bad day at work.
|
||||
|
||||
"Ideally," one sysadmin wisely observes, "you should have [two wired Internet connections to two ISPs with separate infrastructures][41]. You do not want to find out both ISPs are dependent on the same fiber cable, for example. Nor do you want to use two local ISPs and find out they are both dependent on Level 3 for their upstream bandwidth."
|
||||
|
||||
Smart sysadmins know their corporate Internet connections [must be business-class connections with a service-level agreement][42] (SLA) that includes a "time to repair" clause. Better still is to get a [dedicated Internet access][43] (DIA) circuit. Technically, they're no different than any other Internet connection. The difference is that a DIA is not a "best effort" connection. Instead, you get a specified amount of bandwidth that is dedicated for your use and comes with a SLA. They're not cheap, but as the saying goes, "Fast. Reliable. Cheap. Pick any two." When it's your business on the line and a storm is coming your way, "reliable" has to be one of your two picks.
|
||||
|
||||
### When the storm skies clear
|
||||
|
||||
You can't prepare for all disasters, but you can plan for many of them. With a well-thought-out and tested disaster recovery and business continuity plan that is followed to the letter, your company can stay afloat while your rivals are drowning.
|
||||
|
||||
### Sysadmins vs. disasters: Lessons for leaders
|
||||
|
||||
* How many times must your IT staff say this: Don't just make backups. Test backups.
|
||||
* No power? No company. Make certain your servers' emergency power is sufficient for your needs and work.
|
||||
* If your company survives a natural disaster--or dodges one--wise sysadmins know that this is the time to ask management for the disaster recovery budget they've been postponing. Because next time, you might not be so lucky.
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.hpe.com/us/en/insights/articles/it-disaster-recovery-sysadmins-vs-natural-disasters-1711.html
|
||||
|
||||
作者：[Steven-J-Vaughan-Nichols][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.hpe.com/us/en/insights/contributors/steven-j-vaughan-nichols.html
|
||||
[1]:https://www.hpe.com/us/en/insights/articles/what-is-disaster-recovery-really-1704.html
|
||||
[2]:https://www.reddit.com/r/sysadmin/comments/6wricr/dear_houston_tx_sysadmins/
|
||||
[3]:https://www.reddit.com/r/sysadmin/comments/6wricr/dear_houston_tx_sysadmins/dma6gse/
|
||||
[4]:https://disastersafety.org/wp-content/uploads/open-for-business-english.pdf
|
||||
[5]:https://www.fema.gov/protecting-your-businesses
|
||||
[6]:http://drbenchmark.org/about-us/our-council/
|
||||
[7]:https://www.prnewswire.com/news-releases/global-benchmark-study-reveals-73-of-companies-are-unprepared-for-disaster-recovery-248359051.html
|
||||
[8]:https://www.reddit.com/r/sysadmin/comments/3cob1k/what_does_your_disaster_recovery_plan_look_like/csxh8sn/
|
||||
[9]:https://www.hpe.com/us/en/resources/servers/datacenter-trends-challenges.html?jumpid=in_insights~510287587~451research_datacenter~sjvnSysadmin
|
||||
[10]:http://www.theregister.co.uk/2015/07/12/surviving_hurricane_katrina
|
||||
[11]:https://theprepared.com/guides/beginners-guide-amateur-ham-radio-preppers/
|
||||
[12]:http://www.npr.org/2017/09/29/554600989/amateur-radio-operators-stepped-in-to-help-communications-with-puerto-rico
|
||||
[13]:http://www8.hp.com/us/en/software/joshua-brusse.html
|
||||
[14]:https://www.microfocus.com/
|
||||
[15]:https://www.reddit.com/r/sysadmin/comments/6wricr/dear_houston_tx_sysadmins/dma87xv/
|
||||
[16]:https://www.hpe.com/us/en/insights/articles/my-boss-asked-me-to-do-what-how-to-handle-worrying-work-requests-1710.html
|
||||
[17]:https://www.hpe.com/us/en/insights/articles/sysadmin-survival-guide-1707.html
|
||||
[18]:https://www.reddit.com/r/sysadmin/comments/6wk92q/any_houston_admins_executing_their_dr_plans_this/dm8xj0q/
|
||||
[19]:https://community.spiceworks.com/how_to/1243-ensure-your-dr-plan-is-ready-for-a-zombie-apocolypse
|
||||
[20]:http://www.datacenterdynamics.com/content-tracks/security-risk/houston-data-centers-withstand-hurricane-harvey/98867.article
|
||||
[21]:https://www.datafoundry.com/
|
||||
[22]:http://www.datacenterknowledge.com/archives/2012/10/30/major-flooding-nyc-data-centers
|
||||
[23]:https://datagram.com/
|
||||
[24]:https://www.reddit.com/r/sysadmin/comments/6yjb3p/shutting_down_everything_blame_irma/
|
||||
[25]:https://www.hpe.com/us/en/insights/articles/everything-you-need-to-know-about-clouds-and-hybrid-it-1701.html
|
||||
[26]:https://www.drj.com/images/surveys_pdf/forrester/2011Forrester_survey.pdf
|
||||
[27]:https://www.drj.com
|
||||
[28]:https://www.reddit.com/r/sysadmin/comments/4x3mmq/datacenter_power_failure_procedures_what_do_yours/d6c71p1/
|
||||
[29]:https://www.reddit.com/r/sysadmin/comments/4x3mmq/datacenter_power_failure_procedures_what_do_yours/
|
||||
[30]:https://cloudandcolocation.com/datacenters/the-westin-building-seattle-data-center/
|
||||
[31]:https://www.techrepublic.com/article/what-to-look-for-in-a-data-center-backup-generator/
|
||||
[32]:http://www.datacenterknowledge.com/archives/2012/10/31/peer-1-mobilizes-diesel-bucket-brigade-at-75-broad
|
||||
[33]:https://www.cogecopeer1.com/
|
||||
[34]:https://www.reddit.com/r/sysadmin/comments/7a6m7n/aws_glacier_archival/
|
||||
[35]:https://www.reddit.com/r/sysadmin/comments/63mypu/the_dangers_of_cloudberry_and_amazon_glacier_how/
|
||||
[36]:https://en.wikiquote.org/wiki/Andrew_S._Tanenbaum
|
||||
[37]:http://www.snia.org/ltfs
|
||||
[38]:https://www.reddit.com/r/sysadmin/comments/5visaq/backups_how_many_of_you_still_have_tapes/de2d0qm/
|
||||
[39]:https://helpcenter.veeam.com/docs/backup/vsphere/failover.html?ver=95
|
||||
[40]:https://www.reddit.com/r/sysadmin/comments/5rttuo/i_love_you_veeam/
|
||||
[41]:https://www.reddit.com/r/sysadmin/comments/5rmqfx/ars_surviving_a_cloudbased_disaster_recovery_plan/dd90auv/
|
||||
[42]:https://www.hpe.com/us/en/insights/articles/how-do-you-evaluate-cloud-service-agreements-and-slas-very-carefully-1705.html
|
||||
[43]:http://www.e-vergent.com/what-is-dedicated-internet-access/
|
||||
@ -1,144 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to detect automatically generated emails)
|
||||
[#]: via: (https://arp242.net/weblog/autoreply.html)
|
||||
[#]: author: (Martin Tournoij https://arp242.net/)
|
||||
|
||||
How to detect automatically generated emails
|
||||
======
|
||||
|
||||
### How to detect automatically generated emails
|
||||
|
||||
|
||||
When you send out an auto-reply from an email system you want to take care to not send replies to automatically generated emails. At best, you will get a useless delivery failure. At words, you will get an infinite email loop and a world of chaos.
|
||||
|
||||
Turns out that reliably detecting automatically generated emails is not always easy. Here are my observations based on writing a detector for this and scanning about 100,000 emails with it (extensive personal archive and company archive).
|
||||
|
||||
### Auto-submitted header
|
||||
|
||||
Defined in [RFC 3834][1].
|
||||
|
||||
This is the ‘official’ standard way to indicate your message is an auto-reply. You should **not** send a reply if `Auto-Submitted` is present and has a value other than `no`.
|
||||
|
||||
### X-Auto-Response-Suppress header
|
||||
|
||||
Defined [by Microsoft][2]
|
||||
|
||||
This header is used by Microsoft Exchange, Outlook, and perhaps some other products. Many newsletters and such also set this. You should **not** send a reply if `X-Auto-Response-Suppress` contains `DR` (“Suppress delivery reports”), `AutoReply` (“Suppress auto-reply messages other than OOF notifications”), or `All`.
|
||||
|
||||
### List-Id and List-Unsubscribe headers
|
||||
|
||||
Defined in [RFC 2919][3]
|
||||
|
||||
You usually don’t want to send auto-replies to mailing lists or news letters. Pretty much all mail lists and most newsletters set at least one of these headers. You should **not** send a reply if either of these headers is present. The value is unimportant.
|
||||
|
||||
### Feedback-ID header
|
||||
|
||||
Defined [by Google][4].
|
||||
|
||||
Gmail uses this header to identify mail newsletters, and uses it to generate statistics/reports for owners of those newsletters. You should **not** send a reply if this headers is present; the value is unimportant.
|
||||
|
||||
### Non-standard ways
|
||||
|
||||
The above methods are well-defined and clear (even though some are non-standard). Unfortunately some email systems do not use any of them :-( Here are some additional measures.
|
||||
|
||||
#### Precedence header
|
||||
|
||||
Not really defined anywhere, mentioned in [RFC 2076][5] where its use is discouraged (but this header is commonly encountered).
|
||||
|
||||
Note that checking for the existence of this field is not recommended, as some ails use `normal` and some other (obscure) values (this is not very common though).
|
||||
|
||||
My recommendation is to **not** send a reply if the value case-insensitively matches `bulk`, `auto_reply`, or `list`.
|
||||
|
||||
#### Other obscure headers
|
||||
|
||||
A collection of other (somewhat obscure) headers I’ve encountered. I would recommend **not** sending an auto-reply if one of these is set. Most mails also set one of the above headers, but some don’t (but it’s not very common).
|
||||
|
||||
* `X-MSFBL`; can’t really find a definition (Microsoft header?), but I only have auto-generated mails with this header.
|
||||
|
||||
* `X-Loop`; not really defined anywhere, and somewhat rare, but sometimes it’s set. It’s most often set to the address that should not get emails, but `X-Loop: yes` is also encountered.
|
||||
|
||||
* `X-Autoreply`; fairly rare, and always seems to have a value of `yes`.
|
||||
|
||||
|
||||
|
||||
|
||||
#### Email address
|
||||
|
||||
Check if the `From` or `Reply-To` headers contains `noreply`, `no-reply`, or `no_reply` (regex: `^no.?reply@`).
|
||||
|
||||
#### HTML only
|
||||
|
||||
If an email only has a HTML part, but no text part it’s a good indication this is an auto-generated mail or newsletter. Pretty much all mail clients also set a text part.
|
||||
|
||||
#### Delivery failures
|
||||
|
||||
Many delivery failure messages don’t really indicate that they’re failures. Some ways to check this:
|
||||
|
||||
* `From` contains `mailer-daemon` or `Mail Delivery Subsystem`
|
||||
|
||||
|
||||
|
||||
Many mail libraries leave some sort of footprint, and most regular mail clients override this with their own data. Checking for this seems to work fairly well.
|
||||
|
||||
* `X-Mailer: Microsoft CDO for Windows 2000` – Set by some MS software; I can only find it on autogenerated mails. Yes, it’s still used in 2015.
|
||||
|
||||
* `Message-ID` header contains `.JavaMail.` – I’ve found a few (5 on 50k) regular messages with this, but not many; the vast majority (thousends) of messages are news-letters, order confirmations, etc.
|
||||
|
||||
* `^X-Mailer` starts with `PHP`. This should catch both `X-Mailer: PHP/5.5.0` and `X-Mailer: PHPmailer blah blah`. The same as `JavaMail` applies.
|
||||
|
||||
* `X-Library` presence; only [Indy][6] seems to set this.
|
||||
|
||||
* `X-Mailer` starts with `wdcollect`. Set by some Plesk mails.
|
||||
|
||||
* `X-Mailer` starts with `MIME-tools`.
|
||||
|
||||
|
||||
|
||||
|
||||
### Final precaution: limit the number of replies
|
||||
|
||||
Even when following all of the above advice, you may still encounter an email program that will slip through. This can very dangerous, as email systems that simply `IF email THEN send_email` have the potential to cause infinite email loops.
|
||||
|
||||
For this reason, I recommend keeping track of which emails you’ve sent an autoreply to and rate limiting this to at most n emails in n minutes. This will break the back-and-forth chain.
|
||||
|
||||
We use one email per five minutes, but something less strict will probably also work well.
|
||||
|
||||
### What you need to set on your auto-response
|
||||
|
||||
The specifics for this will vary depending on what sort of mails you’re sending. This is what we use for auto-reply mails:
|
||||
|
||||
```
|
||||
Auto-Submitted: auto-replied
|
||||
X-Auto-Response-Suppress: All
|
||||
Precedence: auto_reply
|
||||
```
|
||||
|
||||
### Feedback
|
||||
|
||||
You can mail me at [martin@arp242.net][7] or [create a GitHub issue][8] for feedback, questions, etc.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://arp242.net/weblog/autoreply.html
|
||||
|
||||
作者：[Martin Tournoij][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://arp242.net/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: http://tools.ietf.org/html/rfc3834
|
||||
[2]: https://msdn.microsoft.com/en-us/library/ee219609(v=EXCHG.80).aspx
|
||||
[3]: https://tools.ietf.org/html/rfc2919)
|
||||
[4]: https://support.google.com/mail/answer/6254652?hl=en
|
||||
[5]: http://www.faqs.org/rfcs/rfc2076.html
|
||||
[6]: http://www.indyproject.org/index.en.aspx
|
||||
[7]: mailto:martin@arp242.net
|
||||
[8]: https://github.com/Carpetsmoker/arp242.net/issues/new
|
||||
@ -1,264 +0,0 @@
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: " "
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
[#]: subject: "How To Parse And Pretty Print JSON With Linux Commandline Tools"
|
||||
[#]: via: "https://www.ostechnix.com/how-to-parse-and-pretty-print-json-with-linux-commandline-tools/"
|
||||
[#]: author: "EDITOR https://www.ostechnix.com/author/editor/"
|
||||
|
||||
How To Parse And Pretty Print JSON With Linux Commandline Tools
|
||||
======
|
||||
|
||||
**JSON** is a lightweight and language independent data storage format, easy to integrate with most programming languages and also easy to understand by humans, of course when properly formatted. The word JSON stands for **J** ava **S** cript **O** bject **N** otation, though it starts with JavaScript, and primarily used to exchange data between server and browser, but now being used in many fields including embedded systems. Here we’re going to parse and pretty print JSON with command line tools on Linux. It’s extremely useful for handling large JSON data in a shell scripts, or manipulating JSON data in a shell script.
|
||||
|
||||
### What is pretty printing?
|
||||
|
||||
The JSON data is structured to be somewhat more human readable. However in most cases, JSON data is stored in a single line, even without a line ending character.
|
||||
|
||||
Obviously that’s not very convenient for reading and editing manually.
|
||||
|
||||
That’s when pretty print is useful. The name is quite self explanatory, re-formatting the JSON text to be more legible by humans. This is known as **JSON pretty printing**.
|
||||
|
||||
### Parse And Pretty Print JSON With Linux Commandline Tools
|
||||
|
||||
JSON data could be parsed with command line text processors like **awk** , **sed** and **gerp**. In fact JSON.awk is an awk script to do that. However there are some dedicated tools for the same purpose.
|
||||
|
||||
1. **jq** or **jshon** , JSON parser for shell, both of them are quite useful.
|
||||
|
||||
2. Shell scripts like **JSON.sh** or **jsonv.sh** to parse JSON in bash, zsh or dash shell.
|
||||
|
||||
3. **JSON.awk** , JSON parser awk script.
|
||||
|
||||
4. Python modules like **json.tool**.
|
||||
|
||||
5. **underscore-cli** , Node.js and javascript based.
|
||||
|
||||
|
||||
|
||||
|
||||
In this tutorial I’m focusing only on **jq** , which is quite powerful JSON parser for shells with advanced filtering and scripting capability.
|
||||
|
||||
### JSON pretty printing
|
||||
|
||||
JSON data could be in one and nearly illegible for humans, so to make it somewhat readable, JSON pretty printing is here.
|
||||
|
||||
**Example:** A data from **jsonip.com** , to get external IP address in JSON format, use **curl** or **wget** tools like below.
|
||||
|
||||
```
|
||||
$ wget -cq http://jsonip.com/ -O -
|
||||
```
|
||||
|
||||
The actual data looks like this:
|
||||
|
||||
```
|
||||
{"ip":"111.222.333.444","about":"/about","Pro!":"http://getjsonip.com"}
|
||||
```
|
||||
|
||||
Now pretty print it with jq:
|
||||
|
||||
```
|
||||
$ wget -cq http://jsonip.com/ -O - | jq '.'
|
||||
```
|
||||
|
||||
This should look like below, after filtering the result with jq.
|
||||
|
||||
```
|
||||
{
|
||||
|
||||
"ip": "111.222.333.444",
|
||||
|
||||
"about": "/about",
|
||||
|
||||
"Pro!": "http://getjsonip.com"
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
The Same thing could be done with python **json.tool** module. Here is an example:
|
||||
|
||||
```
|
||||
$ cat anything.json | python -m json.tool
|
||||
```
|
||||
|
||||
This Python based solution should be fine for most users, but it’s not that useful where Python is not pre-installed or could not be installed, like on embedded systems.
|
||||
|
||||
However the json.tool python module has a distinct advantage, it’s cross platform. So, you can use it seamlessly on Windows, Linux or mac OS.
|
||||
|
||||
|
||||
### How to parse JSON with jq
|
||||
|
||||
First, you need to install jq, it’s already picked up by most GNU/Linux distributions, install it with their respective package installer commands.
|
||||
|
||||
On Arch Linux:
|
||||
|
||||
```
|
||||
$ sudo pacman -S jq
|
||||
```
|
||||
|
||||
On Debian, Ubuntu, Linux Mint:
|
||||
|
||||
```
|
||||
$ sudo apt-get install jq
|
||||
```
|
||||
|
||||
On Fedora:
|
||||
|
||||
```
|
||||
$ sudo dnf install jq
|
||||
```
|
||||
|
||||
On openSUSE:
|
||||
|
||||
```
|
||||
$ sudo zypper install jq
|
||||
```
|
||||
|
||||
For other OS or platforms, see the [official installation instructions][1].
|
||||
|
||||
**Basic filters and identifiers of jq**
|
||||
|
||||
jq could read the JSON data either from **stdin** or a **file**. You’ve to use both depending on the situation.
|
||||
|
||||
The single symbol of **.** is the most basic filter. These filters are also called as **object identifier-index**. Using a single **.** along with jq basically pretty prints the input JSON file.
|
||||
|
||||
**Single quotes** – You don’t have to use the single quote always. But if you’re combining several filters in a single line, then you must use them.
|
||||
|
||||
**Double quotes** – You’ve to enclose any special character like **@** , **#** , **$** within two double quotes, like this example, **jq .foo.”@bar”**
|
||||
|
||||
**Raw data print** – For any reason, if you need only the final parsed data, not enclosed within a double quote, use the -r flag with the jq command, like this. **– jq -r .foo.bar**.
|
||||
|
||||
**Parsing specific data**
|
||||
|
||||
To filter out a specific part of JSON, you’ve to look into the pretty printed JSON file’s data hierarchy.
|
||||
|
||||
An example of JSON data, from Wikipedia:
|
||||
|
||||
```
|
||||
{
|
||||
|
||||
"firstName": "John",
|
||||
|
||||
"lastName": "Smith",
|
||||
|
||||
"age": 25,
|
||||
|
||||
"address": {
|
||||
|
||||
"streetAddress": "21 2nd Street",
|
||||
|
||||
"city": "New York",
|
||||
|
||||
"state": "NY",
|
||||
|
||||
"postalCode": "10021"
|
||||
|
||||
},
|
||||
|
||||
"phoneNumber": [
|
||||
|
||||
{
|
||||
|
||||
"type": "home",
|
||||
|
||||
"number": "212 555-1234"
|
||||
|
||||
},
|
||||
|
||||
{
|
||||
|
||||
"type": "fax",
|
||||
|
||||
"number": "646 555-4567"
|
||||
|
||||
}
|
||||
|
||||
],
|
||||
|
||||
"gender": {
|
||||
|
||||
"type": "male"
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
I’m going to use this JSON data as an example in this tutorial, saved this as **sample.json**.
|
||||
|
||||
Let’s say I want to filter out the address from sample.json file. So the command should be like:
|
||||
|
||||
```
|
||||
$ jq .address sample.json
|
||||
```
|
||||
|
||||
**Sample output:**
|
||||
|
||||
```
|
||||
{
|
||||
|
||||
"streetAddress": "21 2nd Street",
|
||||
|
||||
"city": "New York",
|
||||
|
||||
"state": "NY",
|
||||
|
||||
"postalCode": "10021"
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
Again let’s say I want the postal code, then I’ve to add another **object identifier-index** , i.e. another filter.
|
||||
|
||||
```
|
||||
$ cat sample.json | jq .address.postalCode
|
||||
```
|
||||
|
||||
Also note that the **filters are case sensitive** and you’ve to use the exact same string to get something meaningful output instead of null.
|
||||
|
||||
**Parsing elements from JSON array**
|
||||
|
||||
Elements of JSON array are enclosed within square brackets, undoubtedly quite versatile to use.
|
||||
|
||||
To parse elements from a array, you’ve to use the **[]identifier** along with other object identifier-index.
|
||||
|
||||
In this sample JSON data, the phone numbers are stored inside an array, to get all the contents from this array, you’ve to use only the brackets, like this example.
|
||||
|
||||
```
|
||||
$ jq .phoneNumber[] sample.json
|
||||
```
|
||||
|
||||
Let’s say you just want the first element of the array, then use the array object numbers starting for 0, for the first item, use **[0]** , for the next items, it should be incremented by one each step.
|
||||
|
||||
```
|
||||
$ jq .phoneNumber[0] sample.json
|
||||
```
|
||||
|
||||
**Scripting examples**
|
||||
|
||||
Let’s say I want only the the number for home, not entire JSON array data. Here’s when scripting within jq command comes handy.
|
||||
|
||||
```
|
||||
$ cat sample.json | jq -r '.phoneNumber[] | select(.type == "home") | .number'
|
||||
```
|
||||
|
||||
Here first I’m piping the results of one filer to another, then using the select attribute to select a particular type of data, again piping the result to another filter.
|
||||
|
||||
Explaining every type of jq filters and scripting is beyond the scope and purpose of this tutorial. It’s highly suggested to read the JQ manual for better understanding given below.
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/how-to-parse-and-pretty-print-json-with-linux-commandline-tools/
|
||||
|
||||
作者：[EDITOR][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.ostechnix.com/author/editor/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://stedolan.github.io/jq/download/
|
||||
@ -0,0 +1,172 @@
|
||||
IT 灾备：系统管理员对抗自然灾害 | HPE
|
||||
======
|
||||
|
||||
|
||||
|
||||
面对倾泻的洪水或地震时业务需要继续运转。在飓风卡特里娜、桑迪和其他灾难中幸存下来的系统管理员向在紧急状况下负责 IT 的人们分享真实世界中的建议。
|
||||
|
||||
说到自然灾害，2017 年可算是多灾多难。飓风哈维，厄玛和玛莉亚给休斯顿，波多黎各，弗罗里达和加勒比造成了严重破坏。此外，西部的野火将多处住宅和商业建筑付之一炬。
|
||||
|
||||
再来一篇关于[有备无患][1]的警示文章——当然其中都是好的建议——是很简单的，但这无法帮助网络管理员应对湿漉漉的烂摊子。那些善意的建议中大多数都假定掌权的人乐于投入资金来实施这些建议。
|
||||
|
||||
我们对真实世界更感兴趣。不如让我们来充分利用这些坏消息。
|
||||
|
||||
一个很好的例子：自然灾害的一个后果是老板可能突然愿意给灾备计划投入预算。如同一个纽约地区的系统管理员所言，“[我发现飓风桑迪的最大好处][2]是我们的客户对 IT 投资更有兴趣了，但愿你也能得到更多预算。”
|
||||
|
||||
不过别指望这种意愿持续很久。任何想提议改进基础设施的系统管理员最好趁热打铁。如同另一位飓风桑迪中幸存下来的 IT 专员懊悔地提及那样，“[对 IT 开支最初的兴趣持续到当年为止][3]。到了第二年，任何尚未开工的计划都因为‘预算约束’被搁置了，大约 6 个月之后则完全被遗忘。”
|
||||
|
||||
在管理层忘记恶劣的自然灾害也可能降临到好公司头上之前提醒他们这点会有所帮助。根据<ruby>商业和家庭安全协会<rt>Institute for Business & Home Safety</rt></ruby>的说法，[自然灾害后歇业的公司中 25% 再也没能重新开业][4]。<ruby>联邦紧急事务管理署<rt>FEMA</rt></ruby>认为这过于乐观。根据他们的统计，“灾后 [40% 的小公司再也没能重新开门营业][5]。”
|
||||
|
||||
如果你是个系统管理员，你能帮忙挽救你的公司。这里有一些幸存者的最好的主意，这些主意是基于他们从过去几次自然灾害中得到的经验。
|
||||
|
||||
### 制订一个计划
|
||||
|
||||
当灯光忽明忽暗，狂风象火车机车一样怒号时，就该启动你的业务持续计划和灾备计划了。
|
||||
|
||||
有太多的系统管理员报告当暴风雨来临时这两个计划中一个也没有。这并不令人惊讶。2014 年[<ruby>灾备预备状态委员会<rt>Disaster Recovery Preparedness Council</rt></ruby>][6]发现[世界范围内被调查的公司中有 73% 没有足够的灾备计划][7]。
|
||||
|
||||
“足够”是关键词。正如一个系统管理员2016年在 Reddit 上写的那样，“[我们的灾备计划就是一场灾难。][8]我们所有的数据都备份在离这里大约 30 英里的一个<ruby>存储区域网络<rt>SAN</rt></ruby>。我们没有将数据重新上线的硬件，甚至好几天过去了都没能让核心服务器启动运行起来。我们是个年营收 40 亿美元的公司，却不愿为适当的设备投入几十万美元，或是在数据中心添置几台服务器。当添置硬件的提案被提出的时候，我们的管理层说，‘嗐，碰到这种事情的机会能有多大呢’。”
|
||||
|
||||
同一个帖子中另一个人说得更简洁：“眼下我的灾备计划只能在黑暗潮湿的角落里哭泣，但愿没人在乎损失的任何东西。”
|
||||
|
||||
如果你在哭泣，但愿你至少不是独自流泪。任何灾备计划，即便是 IT 部门制订的灾备计划，必须确定[你能跟别人通讯][10]，如同系统管理员 Jim Thompson 从卡特里娜飓风中得到的教训：“确保你有一个与人们通讯的计划。在一场严重的区域性灾难期间，你将无法给身处灾区的任何人打电话。”
|
||||
|
||||
有一个选择可能会让有技术头脑的人感兴趣：[<ruby>业余电台<rt>ham radio</rt></ruby>][11]。[它在波多黎各发挥了巨大作用][12]。
|
||||
|
||||
### 列一个愿望清单
|
||||
|
||||
第一步是承认问题。“许多公司实际上对灾备计划不感兴趣，或是消极对待”，[Micro Focus][14] 的首席架构师 [Joshua Focus][13] 说。“将灾备看作业务持续性的一个方面是种不同的视角。所有公司都要应对业务持续性，所以灾备应被视为业务持续性的一部分。”
|
||||
|
||||
IT 部门需要将其需求书面化以确保适当的灾备和业务持续性计划。即使是你不知道如何着手，或尤其是这种时候，也是如此。正如一个系统管理员所言，“我喜欢有一个‘想法转储’，让所有计划，点子，改进措施毫无保留地提出来。[这][对一类情况尤其有帮助，即当你提议变更][15]，并付诸实施，接着 6 个月之后你警告过的状况就要来临。”现在你做好了一切准备并且可以开始讨论：“如同我们之前在 4 月讨论过的那样……”
|
||||
|
||||
因此，当你的管理层对业务持续性计划回应道“嗐，碰到这种事的机会能有多大呢？”的时候你能做些什么呢？有个系统管理员称这也完全是管理层的正常行为。在这种糟糕的处境下，老练的系统管理员建议用书面形式把这些事情记录下来。记录应清楚表明你告知管理层需要采取的措施，且[他们拒绝采纳建议][16]。“总的来说就是有足够的书面材料能让他们搓成一根绳子上吊，”该系统管理员补充道。
|
||||
|
||||
如果那也不起作用，恢复一个被洪水淹没的数据中心的相关经验对你[找个新工作][17]是很有帮助的。
|
||||
|
||||
### 保护有形的基础设施
|
||||
|
||||
“[我们的办公室是幢摇摇欲坠的建筑][18]，”飓风哈维重创休斯顿之后有个系统管理员提到。“我们盲目地进入那幢建筑，现场的基础设施糟透了。正是我们给那幢建筑里带去了最不想要的一滴水，现在基础设施整个都沉在水下了。”
|
||||
|
||||
尽管如此，如果你想让数据中心继续运转——或在暴风雨过后恢复运转——你需要确保该场所不仅能经受住你所在地区那些意料中的灾难，而且能经受住那些意料之外的灾难。一个旧金山的系统管理员知道为什么重要的是确保公司的服务器安置在可以承受里氏 7 级地震的建筑内。一家圣路易斯的公司知道如何应对龙卷风。但你应当为所有可能发生的事情做好准备：加州的龙卷风，密苏里州的地震，或[僵尸末日][19]（给你在 IT 预算里增加一把链锯提供了充分理由）。
|
||||
|
||||
在休斯顿的情况下，[多数数据中心保持运转][20]，因为它们是按照抵御暴风雨和洪水的标准建造的。[Data Foundry][21] 的首席技术官 Edward Henigin 说他们公司的数据中心之一，“专门建造的休斯顿 2 号的设计能抵御 5 级飓风的风速。这个场所的公共供电没有中断，我们得以避免切换到后备发电机。”
|
||||
|
||||
那是好消息。坏消息是伴随着超级飓风桑迪于2012年登场，如果[你的数据中心没准备好应对洪水][22]，你会陷入一个麻烦不断的世界。一个不能正常运转的数据中心 [Datagram][23] 服务的客户包括 Gawker，Gizmodo 和 Buzzfeed 等知名网站。
|
||||
|
||||
当然，有时候你什么也做不了。正如某个波多黎各圣胡安的系统管理员在飓风厄玛扫过后悲伤地写到，“发电机没油了。服务器机房靠电池在运转但是没有[空调]。[永别了，服务器][24]。”由于 <ruby>MPLS<rt>Multiprotocol Lable Switching</rt></ruby> 线路亦中断，该系统管理员没法切换到灾备措施：“多么充实的一天。”
|
||||
|
||||
总而言之，IT 专业人士需要了解他们所处的地区，了解他们面临的风险并将他们的服务器安置在能抵御当地自然灾害的数据中心内。
|
||||
|
||||
### 关于云的争议
|
||||
|
||||
当暴风雨席卷一切时避免 IT 数据中心失效的最佳方法就是确保灾备数据中心在其他地方。选择地点时需要审慎的决策。你的灾备数据中心不应在会被同一场自然灾害影响到的<ruby>地域<rt>region</rt></ruby>；你的资源应安置在多个<ruby>可用区<rt>availability zone</rt></ruby>内。考虑一下主备数据中心位于一场地震中的同一条断层带上，或是主备数据中心易于受互通河道导致的洪灾影响这类情况。
|
||||
|
||||
有些系统管理员[利用云作为冗余设施][25]。例如，总是用微软 Azure 云存储服务保存副本以确保持久性和高可用性。根据你的选择，Azure 复制功能将你的数据要么拷贝到同一个数据中心要么拷贝到另一个数据中心。多数公有云提供类似的自动备份服务以确保数据安全，不论你的数据中心发生什么情况——除非你的云服务供应商全部设施都在暴风雨的行进路径上。
|
||||
|
||||
昂贵么？是的。跟业务中断 1、2 天一样昂贵么？并非如此。
|
||||
|
||||
信不过公有云？可以考虑 <ruby>colo<rt>colocation</rt></ruby> 服务。有了 colo，你依旧拥有你的硬件，运行你自己的应用，但这些硬件可以远离麻烦。例如飓风哈维期间，一家公司“虚拟地”将它的资源从休斯顿搬到了其位于德克萨斯奥斯汀的 colo。但是那些本地数据中心和 colo 场所需要准备好应对灾难；这点是你选择场所时要考虑的一个因素。举个例子，一个寻找 colo 场所的西雅图系统管理员考虑的“全都是抗震和旱灾应对措施（加固的地基以及补给冷却系统的运水卡车）。”
|
||||
|
||||
### 周围一片黑暗时
|
||||
|
||||
正如 Forrester Research 的分析师 Rachel Dines 在一份为[灾备期刊][27]所做的调查中报告的那样，宣布的灾难中[最普遍的原因就是断电][26]。尽管你能应对一般情况下的断电，飓风、火灾和洪水的考验会超越设备的极限。
|
||||
|
||||
某个系统管理员挖苦式的计划是什么呢？“趁 UPS 完蛋之前把你能关的机器关掉，不能关的就让它崩溃咯。然后，[喝个痛快直到供电恢复][28]。”
|
||||
|
||||
在 2016 年德尔塔和西南航空停电事故之后，IT 员工驱动的一个更加严肃的计划是由一个有管理的服务供应商为其客户[部署不间断电源][29]：“对于至关重要的部分，在供电中断时我们结合使用<ruby>简单网络管理协议<rt>SNMP</rt></ruby>信令和 <ruby>PowerChute 网络关机<rt>PowerChute Nrework Shutdown</rt></ruby>客户端来关闭设备。至于重新开机，那取决于客户。有些是自动启动，有些则需要人工干预。”
|
||||
|
||||
另一种做法是用来自两个供电所的供电线路支持数据中心。例如，[西雅图威斯汀大厦数据中心][30]有来自不同供电所的多路 13.4 千伏供电线路，以及多个 480 伏三相变电箱。
|
||||
|
||||
预防严重断电的系统不是“通用的”设备。系统管理员应当[为数据中心请求一台定制的柴油发电机][31]。除了按你特定的需求调整，发电机必须能迅速跳至全速运转并承载全部电力负荷而不致影响系统负载性能。”
|
||||
|
||||
这些发电机也必须加以保护。例如，将你的发电机安置在泛洪区的一楼就不是个聪明的主意。位于纽约<ruby>百老街<rt>Broad street</rt></ruby>的数据中心在超级飓风桑迪期间就是类似情形，备用发电机的燃料油桶在地下室——并且被水淹了。尽管一场[“人力接龙”用容量 5 加仑的水桶将柴油输送到 17 段楼梯之上的发电机][32]使 [Peer 1 Hosting][33] 得以继续运营，这不是一个切实可行的业务持续计划。
|
||||
|
||||
正如多数数据中心专家所知那样，如果你有时间——假设一个飓风离你有一天的距离——确保你的发电机正常工作，加满油，准备好当供电线路被刮断时立即开启，不管怎样你之前应当每月测试你的发电机。你之前是那么做的，是吧？是就好！
|
||||
|
||||
### 测试你对备份的信心
|
||||
|
||||
普通用户几乎从不备份，检查备份是否实际完好的就更少了。系统管理员对此更加了解。
|
||||
|
||||
有些 [IT 部门在寻求将他们的备份迁移到云端][34]。但有些系统管理员仍对此不买账——他们有很好的理由。最近有人报告，“在用了整整 5 天[从亚马逊 Glacier 恢复了 [400 GB] 数据][35]之后，我欠了亚马逊将近 200 美元的传输费，并且[我还是]处于未完全恢复状态，还差大约 100 GB 文件。
|
||||
|
||||
结果是有些系统管理员依然喜欢磁带备份。磁带肯定不够时髦，但正如操作系统专家 Andrew S. Tanenbaum 说的那样，“[永远不要低估一辆装满磁带在高速上飞驰的旅行车的带宽][36]。”
|
||||
|
||||
目前每盘磁带可以存储 10 TB 数据；有的进行中的实验可在磁带上存储高达 200 TB 数据。诸如[<ruby>线性磁带文件系统<rt>Linear Tape File System</rt></ruby>][37]之类的技术允许你象访问网络硬盘一样读取磁带数据。
|
||||
|
||||
然而对许多人而言，磁带[绝对是最后选择的手段][38]。没关系，因为备份应该有大量的可选方案。在这种情况下，一个系统管理员说到，“故障时我们会用这些方法（恢复备份）：[Windows] 服务器层面的 VSS [Volume Shadow Storage] 快照，<ruby>存储区域网络<rt>SAN</rt></ruby>层面的卷快照，以及存储区域网络层面的异地归档快照。但是万一有什么事情发生并摧毁了我们的虚拟机，存储区域网络和备份存储区域网络，我们还是可以取回磁带并恢复数据。”
|
||||
|
||||
当麻烦即将到来时，可使用副本工具如 [Veeam][39]，它会为你的服务器创建一个虚拟机副本。若出现故障，副本会自动启动。没有麻烦，没有手忙脚乱，正如某个系统管理员在这个流行的系统管理员帖子中所说，“[我爱你 Veeam][40]。”
|
||||
|
||||
### 网络？什么网络？
|
||||
|
||||
当然，如果员工们无法触及他们的服务，没有任何云，colo 和远程数据中心能帮到你。你不需要一场自然灾害来证明冗余互联网连接的正确性。只需要一台挖断线路的挖掘机或断掉的光缆就能让你在工作中渡过糟糕的一天。
|
||||
|
||||
“理想状态下”，某个系统管理员明智地观察到，“你应该有[两路互联网接入线路连接到有独立基础设施的两个 ISP][41]。例如，你不希望两个 ISP 都依赖于同一根光缆。你也不希望采用两家本地 ISP，并发现他们的上行带宽都依赖于同一家骨干网运营商。”
|
||||
|
||||
聪明的系统管理员知道他们公司的互联网接入线路[必须是商业级别的，带有<ruby>服务等级协议<rt>service-level agreement(SLA)</rt></ruby>][43]，其中包含“修复时间”条款。或者更好的是采用<ruby>互联网接入专线<rt></rt>dedicated Internet access</ruby>。技术上这与任何其他互联网接入方式没有区别。区别在于互联网接入专线不是一种“尽力而为”的接入方式，而是你会得到明确规定的专供你使用的带宽并附有服务等级协议。这种专线不便宜，但正如一句格言所说的那样，“速度，可靠性，便宜，只能挑两个。”当你的业务跑在这条线路上并且一场暴风雨即将来袭，“可靠性”必须是你挑的两个之一。
|
||||
|
||||
### 晴空重现之时
|
||||
|
||||
你没法准备应对所有自然灾害，但你可以为其中很多做好计划。有一个深思熟虑且经过测试的灾备和业务持续计划，并逐字逐句严格执行，当竞争对手溺毙的时候，你的公司可以幸存下来。
|
||||
|
||||
### 系统管理员对抗自然灾害：给领导者的教训
|
||||
|
||||
* 你的 IT 员工得说多少次：不要仅仅备份，还得测试备份？
|
||||
* 没电就没公司。确保你的服务器有足够的应急电源来满足业务需要，并确保它们能正常工作。
|
||||
* 如果你的公司在一场自然灾害中幸存下来——或者避开了灾害——明智的系统管理员知道这就是向管理层申请被他们推迟的灾备预算的时候了。因为下次你就未必有这么幸运了。
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.hpe.com/us/en/insights/articles/it-disaster-recovery-sysadmins-vs-natural-disasters-1711.html
|
||||
|
||||
作者：[Steven-J-Vaughan-Nichols][a]
|
||||
译者：[译者ID](https://github.com/0x996)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.hpe.com/us/en/insights/contributors/steven-j-vaughan-nichols.html
|
||||
[1]:https://www.hpe.com/us/en/insights/articles/what-is-disaster-recovery-really-1704.html
|
||||
[2]:https://www.reddit.com/r/sysadmin/comments/6wricr/dear_houston_tx_sysadmins/
|
||||
[3]:https://www.reddit.com/r/sysadmin/comments/6wricr/dear_houston_tx_sysadmins/dma6gse/
|
||||
[4]:https://disastersafety.org/wp-content/uploads/open-for-business-english.pdf
|
||||
[5]:https://www.fema.gov/protecting-your-businesses
|
||||
[6]:http://drbenchmark.org/about-us/our-council/
|
||||
[7]:https://www.prnewswire.com/news-releases/global-benchmark-study-reveals-73-of-companies-are-unprepared-for-disaster-recovery-248359051.html
|
||||
[8]:https://www.reddit.com/r/sysadmin/comments/3cob1k/what_does_your_disaster_recovery_plan_look_like/csxh8sn/
|
||||
[9]:https://www.hpe.com/us/en/resources/servers/datacenter-trends-challenges.html?jumpid=in_insights~510287587~451research_datacenter~sjvnSysadmin
|
||||
[10]:http://www.theregister.co.uk/2015/07/12/surviving_hurricane_katrina
|
||||
[11]:https://theprepared.com/guides/beginners-guide-amateur-ham-radio-preppers/
|
||||
[12]:http://www.npr.org/2017/09/29/554600989/amateur-radio-operators-stepped-in-to-help-communications-with-puerto-rico
|
||||
[13]:http://www8.hp.com/us/en/software/joshua-brusse.html
|
||||
[14]:https://www.microfocus.com/
|
||||
[15]:https://www.reddit.com/r/sysadmin/comments/6wricr/dear_houston_tx_sysadmins/dma87xv/
|
||||
[16]:https://www.hpe.com/us/en/insights/articles/my-boss-asked-me-to-do-what-how-to-handle-worrying-work-requests-1710.html
|
||||
[17]:https://www.hpe.com/us/en/insights/articles/sysadmin-survival-guide-1707.html
|
||||
[18]:https://www.reddit.com/r/sysadmin/comments/6wk92q/any_houston_admins_executing_their_dr_plans_this/dm8xj0q/
|
||||
[19]:https://community.spiceworks.com/how_to/1243-ensure-your-dr-plan-is-ready-for-a-zombie-apocolypse
|
||||
[20]:http://www.datacenterdynamics.com/content-tracks/security-risk/houston-data-centers-withstand-hurricane-harvey/98867.article
|
||||
[21]:https://www.datafoundry.com/
|
||||
[22]:http://www.datacenterknowledge.com/archives/2012/10/30/major-flooding-nyc-data-centers
|
||||
[23]:https://datagram.com/
|
||||
[24]:https://www.reddit.com/r/sysadmin/comments/6yjb3p/shutting_down_everything_blame_irma/
|
||||
[25]:https://www.hpe.com/us/en/insights/articles/everything-you-need-to-know-about-clouds-and-hybrid-it-1701.html
|
||||
[26]:https://www.drj.com/images/surveys_pdf/forrester/2011Forrester_survey.pdf
|
||||
[27]:https://www.drj.com
|
||||
[28]:https://www.reddit.com/r/sysadmin/comments/4x3mmq/datacenter_power_failure_procedures_what_do_yours/d6c71p1/
|
||||
[29]:https://www.reddit.com/r/sysadmin/comments/4x3mmq/datacenter_power_failure_procedures_what_do_yours/
|
||||
[30]:https://cloudandcolocation.com/datacenters/the-westin-building-seattle-data-center/
|
||||
[31]:https://www.techrepublic.com/article/what-to-look-for-in-a-data-center-backup-generator/
|
||||
[32]:http://www.datacenterknowledge.com/archives/2012/10/31/peer-1-mobilizes-diesel-bucket-brigade-at-75-broad
|
||||
[33]:https://www.cogecopeer1.com/
|
||||
[34]:https://www.reddit.com/r/sysadmin/comments/7a6m7n/aws_glacier_archival/
|
||||
[35]:https://www.reddit.com/r/sysadmin/comments/63mypu/the_dangers_of_cloudberry_and_amazon_glacier_how/
|
||||
[36]:https://en.wikiquote.org/wiki/Andrew_S._Tanenbaum
|
||||
[37]:http://www.snia.org/ltfs
|
||||
[38]:https://www.reddit.com/r/sysadmin/comments/5visaq/backups_how_many_of_you_still_have_tapes/de2d0qm/
|
||||
[39]:https://helpcenter.veeam.com/docs/backup/vsphere/failover.html?ver=95
|
||||
[40]:https://www.reddit.com/r/sysadmin/comments/5rttuo/i_love_you_veeam/
|
||||
[41]:https://www.reddit.com/r/sysadmin/comments/5rmqfx/ars_surviving_a_cloudbased_disaster_recovery_plan/dd90auv/
|
||||
[42]:https://www.hpe.com/us/en/insights/articles/how-do-you-evaluate-cloud-service-agreements-and-slas-very-carefully-1705.html
|
||||
[43]:http://www.e-vergent.com/what-is-dedicated-internet-access/
|
||||
Loading…
Reference in New Issue
Block a user