mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
968f2fc104
118
published/20180731 How to be the lazy sysadmin.md
Normal file
118
published/20180731 How to be the lazy sysadmin.md
Normal file
@ -0,0 +1,118 @@
|
|||||||
|
如何成为一名懒惰的系统管理员
|
||||||
|
======
|
||||||
|
> 我们是聪明地工作，而不是刻苦工作，但仍能把工作做好。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Linux 的系统管理员的工作总是复杂的，并且总是伴随着各种陷阱和障碍。做每件事都没有足够时间，当你想完成那个半秃头老板（PHB）给的任务时，他（只会）不停在你的后面盯着，而最核心的服务器总是在最不合时宜的时间点崩溃，问题和挑战比比皆是。而我发现，成为一名<ruby>懒惰的系统管理员<rt>Lazy SysAdmin</rt></ruby>可以解决这一困境。
|
||||||
|
|
||||||
|
（LCTT 译注：<ruby>[半秃头老板](https://en.wikipedia.org/wiki/Pointy-haired_Boss)<rt>Pointy-Haired Boss</rt></ruby>（PHB），那是[呆伯特漫画](https://zh.wikipedia.org/wiki/%E5%91%86%E4%BC%AF%E7%89%B9)中的角色，缺乏一般知识常识及其职位所应具有的管理能力，爱说大话且富有向物理显示挑战的精神，大概长成下图这样。）
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
我在即将在 Apress 出版的新书 《The Linux Philosophy for SysAdmins》（LCTT 译注：暂译《系统管理员的 Linux 哲学》）中更详细地讨论如何成为一个懒惰的系统管理员，那书预计会在 9 月出版（LCTT 译注：已于 2018 年 8 月出版）。这本的部分内容摘录自该书，特别是第九章，“成为一名懒惰的系统管理员”。在我们讨论如何做到这点前，让我们简单了解一下成为一个名懒惰的系统管理员意味着什么。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 真实生产力 vs. 虚假生产力
|
||||||
|
|
||||||
|
#### 虚假生产力
|
||||||
|
|
||||||
|
在我工作的地方，半秃头老板相信的管理风格叫“<ruby>走动式管理<rt>management by walking around</rt></ruby>”。通过判断某人在不在他的键盘上输入东西，或者至少要看看他们显示器上显示的东西，来判断他们的工作是否有效率。这是一个糟糕的工作场所。各部门间有道很高的行政墙，这会造就了许多的、微小的沟通壁垒，大量无用的文书工作，以及获得任何事情的许可都要等待漫长的时间。因为这样、那样的原因，不可能高效地做任何事情，如果真的是这样，那是非常低效。为了看起来很忙，我们都有自己的一套<ruby>“看起来很忙”的工具包<rt>Look Busy Kits</rt></ruby>（LBK），可能是一些短小的、用来显示一些行为活动的 Bash 脚本，或者是 `top`、`htop`、`iotop` 之类的程序，或者是一些持续显示某些行为活动的监控工具。这种工作场所的风气让人不可能真正高效，我讨厌这种地方，也讨厌那个几乎不可能完成任何有价值的事情的事实。
|
||||||
|
|
||||||
|
这种糟糕场所对真实的系统管理员来讲是场噩梦。没有人会感到快乐。在那里花费四五个月才能完成的事，在其他地方只需的一个早晨。我们没有什么实际工作要做，却要花大量的时间干活来让自己看起来很忙。我们在默默地竞赛，看谁能创造最好的“看起来很忙”的工具包，这就是我们花费最多时间的地方了。那份工作我只做了几个月，但好像已经耗费了一生。如果你看到的这个监狱的表面，你可能会说我们是很懒，因为我们只完成了几乎为 0 的实际工作。
|
||||||
|
|
||||||
|
这是个极端的例子，它完全与我所说的“我是一个懒惰的系统管理员”的意思相反，而做一个懒惰的系统管理是件好事。
|
||||||
|
|
||||||
|
#### 真实生产力
|
||||||
|
|
||||||
|
我很幸运，曾为一些真正的管理者工作过 —— 他们明白，系统管理员的生产力并不是以每天花多少小时敲键盘来衡量。毕竟，即使一只猴子能敲击他们的键盘，但也不能说明结果的价值。
|
||||||
|
|
||||||
|
正如我书中所言：
|
||||||
|
|
||||||
|
> “我是一个懒惰的系统管理员，同时我也是一个高效的系统管理员。这两者看似矛盾的说法不是相互排斥的，而是会以一种非常积极的方式相辅相成……
|
||||||
|
>
|
||||||
|
> “系统管理员在思考的时候是最高效的 —— 思考关于如何解决现有问题和避免未来的问题；思考怎样监控 Linux 计算机，以便找到预测和预示这些未来的问题的线索；思考如何让他们的工作更有效率；思考如何自动化所有这些要执行的任务，无论是每天还是每年一次的任务。
|
||||||
|
>
|
||||||
|
> “系统管理员冥思苦想的那一面是不会被非系统管理员所熟知的，那些人包括很多管理着系统管理员的人，比如那个半秃头老板。系统管理员都会以不同的方式解决他们工作中苦思的部分。一些我认识的系统管理员会在沙滩、骑自行车、参加马拉松或者攀岩时找到最好的想法。另一些人会认为静坐或听音乐的时候思考得最好。还有一些会在阅读小说、学习不相关的学科、甚至在学习 Linux 系统的时候可以最佳思考。关键是我们都有不同的方式激发我们的创造力，而这些创造力的推进器中很多并不涉及键盘上的任何一个按键。我们真正的生产力对于系统管理员周围的人来说可能是完全看不见的。”
|
||||||
|
|
||||||
|
成为懒惰的系统管理员有一些简单的秘诀 —— 系统管理员要完成一切需要完成的事，而且更多的是，当所有人都处于恐慌的状态时要保持冷静和镇定。秘诀的一部分是高效工作，另一部分是把预防问题放在首位。
|
||||||
|
|
||||||
|
### 成为懒惰系统管理员的方法
|
||||||
|
|
||||||
|
#### 多思考
|
||||||
|
|
||||||
|
我相信关于懒惰系统管理员最重要的秘诀在于思考。正如上面的摘录所言，优秀的系统管理员会花大量的时候思考这些事情，如何更有效率地工作，在异常成为问题前如何定位，更聪明地工作，做其它事情的同时会考虑如何完成这些事情等等。
|
||||||
|
|
||||||
|
例如，除了撰写本文之外，我现在正在想一个项目，我打算在从亚马逊和本地计算机商店采购的新部件到达时才开始。我有一台不太关键的计算机上的主板坏了，最近它的崩溃更频率。但我的一台非常老的小服务器并没有出现故障，它负责处理我的电子邮件和外部网站，以及为我的网络的其余部分提供 DHCP 和 DNS 服务，但需要解决由于各种外部攻击而导致的间歇性过载。
|
||||||
|
|
||||||
|
我一开始想，我只要替换故障设备的主板及其直接部件：内存、CPU，可能还有电源。但是在考虑了一段时间之后，我决定将新部件放到服务器中，并将旧的（但仍然可用的）部件从服务器移到故障设备中。可以这样做的，只需一、两个小时就可以从服务器上移除旧部件并安装新的。然后我就可以花时间更换出故障的电脑里的部件了。太好了，所以我开始在脑海中列出要完成的任务。
|
||||||
|
|
||||||
|
然而，当我查看这个任务列表时，我意识到服务器中唯一不能替换的部件是机箱和硬盘驱动器，这两台计算机的机箱几乎完全相同。在有了这个小小的发现之后，我开始考虑用新的部件替换出了故障的计算机的部件，并将之作为我的服务器。经过一些测试之后，我只需从当前的服务器移除硬盘，并将它安装到用了新组件的机箱中，改下网络配置项，再更改 KVM 交换机端口上的主机名，并更改机箱上的主机名标签，就可以了。这将大大减少服务器停机时间，大大减少我的压力。此外，如果出现故障，我可以简单地将硬盘移回原来的服务器，直到我可以用新服务器解决问题为止。
|
||||||
|
|
||||||
|
所以，现在我在脑海中已经创建了一个完成这项工作我所需要做的任务清单。而且，我希望你能仔细观察，当我脑子里想着这一切的时候，我的手指从来没有碰过键盘。我新的心理行动计划风险很低，与我最初的计划相比，涉及的服务器停机时间要少得多。
|
||||||
|
|
||||||
|
当我在 IBM 工作的时候，我经常看到很多语言中都有写着“**思考**”的标语。思考可以节省时间和压力，是懒散的系统管理员的主要标志。
|
||||||
|
|
||||||
|
#### 做预防性维护
|
||||||
|
|
||||||
|
在 1970 年代中期，我被 IBM 聘为客户工程师，我的领地由相当多的[穿孔卡片设备][2]组成。这也就是说，它们是处理打孔卡的重型机械设备，其中一些可以追溯到 20 世纪 30 年代。因为这些机器主要是机械的，所以它们的部件经常磨损或失调。我的部分工作是在它们损坏时修复它们。我工作的主要部分，也是最重要的部分，是首先要防止它们损坏。预防性维护的目的是在磨损部件损坏之前进行更换，并对还在运行的部件进行润滑和调整，以确保它们工作正常。
|
||||||
|
|
||||||
|
正如我在《系统管理员的 Linux 哲学》中所言：
|
||||||
|
|
||||||
|
>“我在 IBM 的经理们明白这只是冰山一角；他们和我都知道，我的工作是让顾客满意。虽然这通常意味着修复损坏的硬件，但也意味着减少硬件损坏的次数。这对客户来说是好事，因为他们的机器在工作时工作效率更高。这对我有好处，因为我从那些快乐的客户那里接到的电话要少得多。我也睡了更多的觉，因为这样做的结果是更少的非工作时间的紧急电话。我是个懒惰的（客户工程师）。通过提前做额外的工作，从长远来看，我需要做的工作要少得多。
|
||||||
|
>
|
||||||
|
>“这一原则已成为系统管理员的 Linux 哲学的功能原则之一。作为系统管理员，我们的时间最好用在最大限度地减少未来工作量的任务上。”
|
||||||
|
|
||||||
|
在 Linux 计算机中查找要解决的问题相当于项目管理。我检查系统日志，寻找以后可能会变得非常危险的问题的迹象。如果出现了一些小问题，或者我注意到我的工作站、服务器没有做出该有的响应，或者如果日志显示了一些不寻常的东西，所有这些都可以暗示出潜在的问题，而对于用户或半秃头老板来说，这些问题并没有产生明显的症状。
|
||||||
|
|
||||||
|
我经常检查 `/var/log/` 中的文件，特别是 `messages` 和 `security` 文件。我最常见的问题之一是许多脚本小子在我的防火墙系统上尝试各种类型的攻击。而且，不，我不依赖 ISP 提供的调制解调器/路由器中的所谓的防火墙。这些日志包含了大量关于企图攻击来源的信息，非常有价值。但是要扫描不同主机上的日志并将解决方案部署到位，需要做大量的工作，所以我转向自动化。
|
||||||
|
|
||||||
|
#### 自动化
|
||||||
|
|
||||||
|
我发现我的工作有很大一部分可以通过某种形式的自动化来完成。系统管理员的 Linux 哲学的原则之一是 “自动化一切”，这包括每天扫描日志文件等枯燥乏味的任务。
|
||||||
|
|
||||||
|
像是 [Logwatch][3] 这类的程序能够监控你的日志文件中的异常条目，并在异常条目发生时通知您。Logwatch 通常作为 cron 任务每天运行一次，并向本地主机上的 root 用户发送电子邮件。你可以从命令行运行 Logwatch，并立即在显示器上查看结果。现在我只需要每天查看 Logwatch 的电子邮件通知。
|
||||||
|
|
||||||
|
但现实是，仅仅收到通知是不够的，因为我们不能坐以待毙。有时需要立即作出反应。我喜欢的另一个程序是——它能为我做所有事（看，这就是懒惰的管理员）——它就是 [Fail2ban][4]。Fail2Ban 会扫描指定的日志文件，查找各种类型的黑客攻击和入侵尝试，如果它发现某个 IP 地址在持续做特定类型的活动，它会向防火墙添加一个条目，在指定的时间内阻止来自该 IP 地址的任何进一步的黑客尝试。默认值通常在 10 分钟左右，但我喜欢为大多数类型的攻击指定为 12 或 24 小时。每种类型的黑客攻击都是单独配置的，例如尝试通过 SSH 登录和那些 Web 服务器的攻击。
|
||||||
|
|
||||||
|
#### 写脚本
|
||||||
|
|
||||||
|
自动化是这种哲学的关键组成部分之一。一切可以自动化的东西都应该自动化的，其余的尽可能地自动化。所以，我也写了很多脚本来解决问题，也就是说我编写了脚本来完成我的大部分工作。
|
||||||
|
|
||||||
|
我的脚本帮我节省了大量时间，因为它们包含执行特定任务的命令，这大大减少了我需要输入的数量。例如，我经常重新启动我的电子邮件服务器和垃圾邮件过滤软件（当修改 SpamAssassin 的 `local.cf` 配置文件时，就需要重启）。必须按特定顺序停止并重新启动这些服务。因此，我用几个命令编写了一个简短的脚本，并将其存储在可访问的 `/usr/local/bin` 中。现在，不用键入几个命令并等待每个命令都完成，然后再键入下一个命令，更不用记住正确的命令顺序和每个命令的正确语法，我输入一个三个字符的命令，其余的留给我的脚本来完成。
|
||||||
|
|
||||||
|
#### 简化键入
|
||||||
|
|
||||||
|
另一种成为懒惰的系统管理员的方法是减少我们需要键入的数量。而且，我的打字技巧真的很糟糕（也就是说，我一点也没有，顶多是几个笨拙的手指）。导致错误的一个可能原因是我糟糕的打字技巧，所以我会尽量少打字。
|
||||||
|
|
||||||
|
绝大多数 GNU 和 Linux 核心实用程序都有非常短的名称。然而，它们都是有意义的名字。诸如用于更改目录的 `cd` 、用于列出目录内容的 `ls` 和用于磁盘转储的 `dd` 等工具都一目了然。短名字意味着更少的打字和更少的产生错误机会。我认为短的名字通常更容易记住。
|
||||||
|
|
||||||
|
当我编写 shell 脚本时，我喜欢保持名称简短而意义（至少对我来说是），比如用于 rsync 备份的 `rsbu`（LCTT 译注，Rsync Backup 的简写）。但在某些情况下，我喜欢使用更长的名称，比如 `doUpdates` 来执行系统更新。在后一种情况下，更长一点的名字让脚本的目的更明显。这可以节省时间，因为很容易记住脚本的名称。
|
||||||
|
|
||||||
|
其他减少键入的方法包括命令行别名、历史命令调回和编辑。别名只是你在 Bash shell 键入命令时才做的替换。键入 `alias` 命令会看到默认配置的别名列表。例如，当你输入命令 `ls` 时，会被条目 `alias ls='ls –color=auto'` 替成较长的命令，因此你只需键入 2 个字符而不是 14 个字符即可获得带有颜色的文件列表。还可以使用 `alias` 命令添加你自己定义的别名。
|
||||||
|
|
||||||
|
历史命令调回允许你使用键盘的向上和向下箭头键滚动浏览命令历史记录。如果需要再次使用相同的命令，只需在找到所需的命令时按回车键即可。如果在找到命令后需要更改该命令，则可以使用标准命令行编辑功能进行更改。
|
||||||
|
|
||||||
|
### 结束语
|
||||||
|
|
||||||
|
一名懒惰的系统管理员实际上也有很多的工作。但我们是聪明地工作，而不是刻苦工作。早在一堆小问题汇聚成大问题之前，我们就花时间探索我们负责的主机，并处理好所有的小问题。我们花了很多时间思考解决问题的最佳方法，我们也花了很多时间来发现新的方法，让自己更聪明地工作，成为懒惰的系统管理员。
|
||||||
|
|
||||||
|
除了这里描述的少数方法外，还有许多其他的方式可以成为懒惰的系统管理员。我相信你也有一些自己的方式；请在评论中和我们分享。
|
||||||
|
|
||||||
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
via: https://opensource.com/article/18/7/how-be-lazy-sysadmin
|
||||||
|
|
||||||
|
作者：[David Both][a]
|
||||||
|
选题：[lujun9972](https://github.com/lujun9972)
|
||||||
|
译者：[zgj1024](https://github.com/zgj1024)
|
||||||
|
校对：[wxy](https://github.com/wxy)
|
||||||
|
|
||||||
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||||
|
|
||||||
|
[a]:https://opensource.com/users/dboth
|
||||||
|
[1]:https://www.apress.com/us/book/9781484237298
|
||||||
|
[2]:https://en.wikipedia.org/wiki/Unit_record_equipment
|
||||||
|
[3]:https://www.techrepublic.com/article/how-to-install-and-use-logwatch-on-linux/
|
||||||
|
[4]:https://www.fail2ban.org/wiki/index.php/Main_Page
|
||||||
@ -1,316 +0,0 @@
|
|||||||
[#]: collector: (lujun9972)
|
|
||||||
[#]: translator: (MjSeven )
|
|
||||||
[#]: reviewer: ( )
|
|
||||||
[#]: publisher: ( )
|
|
||||||
[#]: url: ( )
|
|
||||||
[#]: subject: (YAML: probably not so great after all)
|
|
||||||
[#]: via: (https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html)
|
|
||||||
[#]: author: (Martin Tournoij https://arp242.net/)
|
|
||||||
|
|
||||||
YAML: probably not so great after all
|
|
||||||
======
|
|
||||||
|
|
||||||
|
|
||||||
I previously wrote [why using JSON for human-editable configuration files is a bad idea][1]. Today we’re going to look at some general problems with the YAML format.
|
|
||||||
|
|
||||||
### Insecure by default
|
|
||||||
|
|
||||||
YAML is insecure by default. Loading a user-provided (untrusted) YAML string needs careful consideration.
|
|
||||||
|
|
||||||
```
|
|
||||||
!!python/object/apply:os.system
|
|
||||||
args: ['ls /']
|
|
||||||
```
|
|
||||||
|
|
||||||
Running it with `print(yaml.load(open('a.yaml')))` should give you something like:
|
|
||||||
|
|
||||||
```
|
|
||||||
bin etc lib lost+found opt root sbin tmp var sys
|
|
||||||
boot dev efi home lib64 mnt proc run srv usr
|
|
||||||
0
|
|
||||||
```
|
|
||||||
|
|
||||||
Many other languages (including Ruby and PHP) are also unsafe by default. [Searching for `yaml.load` on GitHub][2] gives a whopping 2.8 million results. [`yaml.safe_load`][3] only gives 26,000 results.
|
|
||||||
|
|
||||||
Mind you, many of those `yaml.load()`s are fine – loading in a config file with `yaml.load()` is often okay since it’s usually (though not always!) from a ‘trusted source’, and many are from test files with static YAML. But still, one can’t help but wonder how many exploits are hidden in those 2.8 million results.
|
|
||||||
|
|
||||||
This is not a theoretical problem. In 2013 [every Ruby on Rails application ever written was found to be vulnerable][4] to remote code execution due to exactly this problem.
|
|
||||||
|
|
||||||
One might argue this is not really the fault of the YAML format as such, but rather the fault of the libraries implementing it wrong, but it seems to be the case that the majority of libraries are unsafe by default (especially the dynamic languages), so de-facto it is a problem with YAML.
|
|
||||||
|
|
||||||
One might also argue that fixing it is as easy as replacing `load()` with `safe_load()`, but many people are unaware of the problem, and even if you’re aware of it, it’s one of those things that can be easy to forget. It’s pretty bad API design.
|
|
||||||
|
|
||||||
### Can be hard to edit, especially for large files
|
|
||||||
|
|
||||||
YAML files can be hard to edit, and this difficulty grows fast as the file gets larger.
|
|
||||||
|
|
||||||
A good example of this are Ruby on Rails’ translation files; for example:
|
|
||||||
|
|
||||||
```
|
|
||||||
en:
|
|
||||||
formtastic:
|
|
||||||
labels:
|
|
||||||
title: "Title" # Default global value
|
|
||||||
article:
|
|
||||||
body: "Article content"
|
|
||||||
post:
|
|
||||||
new:
|
|
||||||
title: "Choose a title..."
|
|
||||||
body: "Write something..."
|
|
||||||
edit:
|
|
||||||
title: "Edit title"
|
|
||||||
body: "Edit body"
|
|
||||||
```
|
|
||||||
|
|
||||||
This still looks okay, right? But what if this file has 100 lines? Or 1,000 lines? It is difficult to see “where” in the file you are because it may be off the screen. You’ll need to scroll up, but then you need to keep track of the indentation, which can be pretty hard even with indentation guides, especially since 2-space indentation is the norm and [tab indentation is forbidden][5].
|
|
||||||
|
|
||||||
And accidentally getting the indentation wrong often isn’t an error; it will often just deserialize to something you didn’t intend. Happy debugging!
|
|
||||||
|
|
||||||
I’ve been happily programming Python for over a decade, so I’m used to significant whitespace, but sometimes I’m still struggling with YAML. In Python the drawbacks and loss of clarity are contained by not having functions that are several pages long, but data or configuration files have no such natural limits to their length.
|
|
||||||
|
|
||||||
For small files this is not a problem; but it really doesn’t scale well to larger files, especially not if you want to edit them later on.
|
|
||||||
|
|
||||||
### It’s pretty complex
|
|
||||||
|
|
||||||
YAML may seem ‘simple’ and ‘obvious’ when glancing at a basic example, but turns out it’s not. The [YAML spec][6] is 23,449 words; for comparison, [TOML][7] is 3,339 words, [JSON][8] is 1,969 words, and [XML][9] is 20,603 words.
|
|
||||||
|
|
||||||
Who among us have read all that? Who among us have read and understood all of that? Who among of have read, understood, and **remembered** all of that?
|
|
||||||
|
|
||||||
For example did you know there are [nine ways to write a multi-line string in YAML][10] with subtly different behaviour?
|
|
||||||
|
|
||||||
Yeah :-/
|
|
||||||
|
|
||||||
That post gets even more interesting if you look at [its revision history][11], as the author of the post discovers more and more ways to do this and more of the subtleties involved.
|
|
||||||
|
|
||||||
It’s telling that the YAML spec starts with a preview, which states (emphases mine):
|
|
||||||
|
|
||||||
> This section provides a quick glimpse into the expressive power of YAML. **It is not expected that the first-time reader grok all of the examples**. Rather, these selections are used as motivation for the remainder of the specification.
|
|
||||||
|
|
||||||
#### Surprising behaviour
|
|
||||||
|
|
||||||
What does this parse to (examples courtesy of [Colm O’Connor][12]):
|
|
||||||
|
|
||||||
```
|
|
||||||
- Don Corleone: Do you have faith in my judgment?
|
|
||||||
- Clemenza: Yes
|
|
||||||
- Don Corleone: Do I have your loyalty?
|
|
||||||
```
|
|
||||||
|
|
||||||
Yup!
|
|
||||||
|
|
||||||
```
|
|
||||||
[
|
|
||||||
{'Don Corleone': 'Do you have faith in my judgment?'},
|
|
||||||
{'Clemenza': True},
|
|
||||||
{'Don Corleone': 'Do I have your loyalty?'}
|
|
||||||
]
|
|
||||||
```
|
|
||||||
|
|
||||||
Or what about:
|
|
||||||
|
|
||||||
```
|
|
||||||
python: 3.5.3
|
|
||||||
postgres: 9.3
|
|
||||||
```
|
|
||||||
|
|
||||||
`3.5.3` gets recognized as as string, but `9.3` gets recognized as a number instead of a string:
|
|
||||||
|
|
||||||
```
|
|
||||||
{'python': '3.5.3', 'postgres': 9.3}
|
|
||||||
```
|
|
||||||
|
|
||||||
Or what about:
|
|
||||||
|
|
||||||
```
|
|
||||||
Effenaar: Eindhoven
|
|
||||||
013: Tilburg
|
|
||||||
```
|
|
||||||
|
|
||||||
013 is a popular music Venue in Tilburg, but YAML will send you the wrong way since it’s parsed as an octal number:
|
|
||||||
|
|
||||||
```
|
|
||||||
{11: 'Tilburg', 'Effenaar': 'Eindhoven'}
|
|
||||||
```
|
|
||||||
|
|
||||||
All of this – and more – is why many experienced YAMLers will often quote all strings, even when it’s not strictly required. Many people don’t use quotes, and it can be easy to forget especially if the rest of the file – possibly written by other people – doesn’t use quotes.
|
|
||||||
|
|
||||||
#### It’s not portable
|
|
||||||
|
|
||||||
Because it’s so complex, its claims of portability have been greatly exaggerated. For example consider this example taken from the YAML spec:
|
|
||||||
|
|
||||||
```
|
|
||||||
? - Detroit Tigers
|
|
||||||
- Chicago cubs
|
|
||||||
:
|
|
||||||
- 2001-07-23
|
|
||||||
|
|
||||||
? [ New York Yankees,
|
|
||||||
Atlanta Braves ]
|
|
||||||
: [ 2001-07-02, 2001-08-12,
|
|
||||||
2001-08-14 ]
|
|
||||||
```
|
|
||||||
|
|
||||||
Aside from the fact that most readers of this probably won’t even know what this does, try parsing it in Python with PyYAML:
|
|
||||||
|
|
||||||
```
|
|
||||||
yaml.constructor.ConstructorError: while constructing a mapping
|
|
||||||
in "a.yaml", line 1, column 1
|
|
||||||
found unhashable key
|
|
||||||
in "a.yaml", line 1, column 3
|
|
||||||
```
|
|
||||||
|
|
||||||
In Ruby it works:
|
|
||||||
|
|
||||||
```
|
|
||||||
{
|
|
||||||
["Detroit Tigers", "Chicago cubs"] => [
|
|
||||||
#<Date: 2001-07-23 ((2452114j,0s,0n),+0s,2299161j)>
|
|
||||||
],
|
|
||||||
["New York Yankees", "Atlanta Braves"] => [
|
|
||||||
#<Date: 2001-07-02 ((2452093j,0s,0n),+0s,2299161j)>,
|
|
||||||
#<Date: 2001-08-12 ((2452134j,0s,0n),+0s,2299161j)>,
|
|
||||||
#<Date: 2001-08-14 ((2452136j,0s,0n),+0s,2299161j)>
|
|
||||||
]
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
The reason for this is because you can’t use a list as a dict key in Python:
|
|
||||||
|
|
||||||
```
|
|
||||||
>>> {['a']: 'zxc'}
|
|
||||||
Traceback (most recent call last):
|
|
||||||
File "<stdin>", line 1, in <module>
|
|
||||||
TypeError: unhashable type: 'list'
|
|
||||||
```
|
|
||||||
|
|
||||||
And this restriction is not unique to Python; common languages such as PHP, JavaScript, and Go all share this restriction.
|
|
||||||
|
|
||||||
So use this in a YAML file, and you won’t be able to read it in most languages.
|
|
||||||
|
|
||||||
Here’s another example again taken from the examples section of the YAML spec:
|
|
||||||
|
|
||||||
```
|
|
||||||
# Ranking of 1998 home runs
|
|
||||||
---
|
|
||||||
- Mark McGwire
|
|
||||||
- Sammy Sosa
|
|
||||||
- Ken Griffey
|
|
||||||
|
|
||||||
# Team ranking
|
|
||||||
---
|
|
||||||
- Chicago Cubs
|
|
||||||
- St Louis Cardinals
|
|
||||||
```
|
|
||||||
|
|
||||||
Python says:
|
|
||||||
|
|
||||||
```
|
|
||||||
yaml.composer.ComposerError: expected a single document in the stream
|
|
||||||
in "a.yaml", line 3, column 1
|
|
||||||
but found another document
|
|
||||||
in "a.yaml", line 8, column 1
|
|
||||||
```
|
|
||||||
|
|
||||||
While Ruby outputs:
|
|
||||||
|
|
||||||
```
|
|
||||||
["Mark McGwire", "Sammy Sosa", "Ken Griffey"]
|
|
||||||
```
|
|
||||||
|
|
||||||
The reason for this is that there are multiple YAML documents in a single file (`---` start the document). In Python there is the `load_all()` function to parse all documents. Ruby’s `load()` just loads the first document, and as near as I can tell, doesn’t have a way to load multiple documents.
|
|
||||||
|
|
||||||
There are [many more incompatibilities between implementations][13].
|
|
||||||
|
|
||||||
### Goals achieved?
|
|
||||||
|
|
||||||
The spec states:
|
|
||||||
|
|
||||||
> The design goals for YAML are, in decreasing priority:
|
|
||||||
>
|
|
||||||
> 1. YAML is easily readable by humans.
|
|
||||||
> 2. YAML data is portable between programming languages.
|
|
||||||
> 3. YAML matches the native data structures of agile languages.
|
|
||||||
> 4. YAML has a consistent model to support generic tools.
|
|
||||||
> 5. YAML supports one-pass processing.
|
|
||||||
> 6. YAML is expressive and extensible.
|
|
||||||
> 7. YAML is easy to implement and use.
|
|
||||||
>
|
|
||||||
|
|
||||||
|
|
||||||
So how well does it do?
|
|
||||||
|
|
||||||
> YAML is easily readable by humans.
|
|
||||||
|
|
||||||
True only if you stick to a small subset. The full set is complex – much more so than XML or JSON.
|
|
||||||
|
|
||||||
> YAML data is portable between programming languages.
|
|
||||||
|
|
||||||
Not really true, as it’s too easy to create constructs that are not supported by common languages.
|
|
||||||
|
|
||||||
> YAML matches the native data structures of agile languages.
|
|
||||||
|
|
||||||
See above. Plus, why only support agile (or dynamic) languages? What about other languages?
|
|
||||||
|
|
||||||
> YAML has a consistent model to support generic tools.
|
|
||||||
|
|
||||||
I am not even sure what this means and I can’t find any elaboration.
|
|
||||||
|
|
||||||
> YAML supports one-pass processing.
|
|
||||||
|
|
||||||
I’ll take their word for it.
|
|
||||||
|
|
||||||
> YAML is expressive and extensible.
|
|
||||||
|
|
||||||
Well, it is, but it’s too expressive (e.g. too complex).
|
|
||||||
|
|
||||||
> YAML is easy to implement and use.
|
|
||||||
|
|
||||||
```
|
|
||||||
$ cat `ls -1 ~/gocode/src/github.com/go-yaml/yaml/*.go | grep -v _test` | wc -l
|
|
||||||
9247
|
|
||||||
|
|
||||||
$ cat /usr/lib/python3.5/site-packages/yaml/*.py | wc -l
|
|
||||||
5713
|
|
||||||
```
|
|
||||||
|
|
||||||
### Conclusion
|
|
||||||
|
|
||||||
Don’t get me wrong, it’s not like YAML is absolutely terrible – it’s certainly not as [problematic as using JSON][1] – but it’s not exactly great either. There are some drawbacks and surprises that are not at all obvious at first, and there are a number of better alternatives such as [TOML][7] and other more specialized formats.
|
|
||||||
|
|
||||||
Personally, I’m not likely to use it again when I’ve got a choice.
|
|
||||||
|
|
||||||
If you must use YAML then I recommend you use [StrictYAML][14], which removes some (though not all) of the more hairy parts.
|
|
||||||
|
|
||||||
### Feedback
|
|
||||||
|
|
||||||
You can mail me at [martin@arp242.net][15] or [create a GitHub issue][16] for feedback, questions, etc.
|
|
||||||
|
|
||||||
--------------------------------------------------------------------------------
|
|
||||||
|
|
||||||
via: https://arp242.net/weblog/yaml_probably_not_so_great_after_all.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://arp242.net/weblog/JSON_as_configuration_files-_please_dont.html
|
|
||||||
[2]: https://github.com/search?q=yaml.load&type=Code&utf8=%E2%9C%93
|
|
||||||
[3]: https://github.com/search?q=yaml.safe_load&type=Code&utf8=%E2%9C%93
|
|
||||||
[4]: https://www.sitepoint.com/anatomy-of-an-exploit-an-in-depth-look-at-the-rails-yaml-vulnerability/
|
|
||||||
[5]: http://www.yaml.org/faq.html
|
|
||||||
[6]: http://yaml.org/spec/1.2/spec.pdf
|
|
||||||
[7]: https://github.com/toml-lang/toml
|
|
||||||
[8]: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
|
|
||||||
[9]: https://www.w3.org/TR/REC-xml/
|
|
||||||
[10]: http://stackoverflow.com/a/21699210/660921
|
|
||||||
[11]: http://stackoverflow.com/posts/21699210/revisions
|
|
||||||
[12]: https://github.com/crdoconnor/strictyaml/blob/master/FAQ.rst#what-is-wrong-with-implicit-typing
|
|
||||||
[13]: https://github.com/cblp/yaml-sucks
|
|
||||||
[14]: https://github.com/crdoconnor/strictyaml
|
|
||||||
[15]: mailto:martin@arp242.net
|
|
||||||
[16]: https://github.com/Carpetsmoker/arp242.net/issues/new
|
|
||||||
@ -1,3 +1,4 @@
|
|||||||
|
LuMing is translating
|
||||||
11 Methods To Find System/Server Uptime In Linux
|
11 Methods To Find System/Server Uptime In Linux
|
||||||
======
|
======
|
||||||
Do you want to know, how long your Linux system has been running without downtime? when the system is up and what date.
|
Do you want to know, how long your Linux system has been running without downtime? when the system is up and what date.
|
||||||
|
|||||||
@ -1,211 +0,0 @@
|
|||||||
How to be the lazy sysadmin
|
|
||||||
======
|
|
||||||
|
|
||||||
|
|
||||||
The job of a Linux SysAdmin is always complex and often fraught with various pitfalls and obstacles. Ranging from never having enough time to do everything, to having the Pointy-Haired Boss (PHB) staring over your shoulder while you try to work on the task that she or he just gave you, to having the most critical server in your care crash at the most inopportune time, problems and challenges abound. I have found that becoming the Lazy Sysadmin can help.
|
|
||||||
|
|
||||||
I discuss how to be a lazy SysAdmin in detail in my forthcoming book, [The Linux Philosophy for SysAdmins][1], (Apress), which is scheduled to be available in September. Parts of this article are taken from that book, especially Chapter 9, "Be a Lazy SysAdmin." Let's take a brief look at what it means to be a Lazy SysAdmin before we discuss how to do it.
|
|
||||||
|
|
||||||
### Real vs. fake productivity
|
|
||||||
|
|
||||||
#### Fake productivity
|
|
||||||
|
|
||||||
At one place I worked, the PHB believed in the management style called "management by walking around," the supposition being that anyone who wasn't typing something on their keyboard, or at least examining something on their display, was not being productive. This was a horrible place to work. It had high administrative walls between departments that created many, tiny silos, a heavy overburden of useless paperwork, and excruciatingly long wait times to obtain permission to do anything. For these and other reasons, it was impossible to do anything efficiently—if at all—so we were incredibly non-productive. To look busy, we all had our Look Busy Kits (LBKs), which were just short Bash scripts that showed some activity, or programs like `top`, `htop`, `iotop`, or any monitoring tool that constantly displayed some activity. The ethos of this place made it impossible to be truly productive, and I hated both the place and the fact that it was nearly impossible to accomplish anything worthwhile.
|
|
||||||
|
|
||||||
That horrible place was a nightmare for real SysAdmins. None of us was happy. It took four or five months to accomplish what took only a single morning in other places. We had little real work to do but spent a huge amount of time working to look busy. We had an unspoken contest going to create the best LBK, and that is where we spent most of our time. I only managed to last a few months at that job, but it seemed like a lifetime. If you looked only at the surface of that dungeon, you could say we were lazy because we accomplished almost zero real work.
|
|
||||||
|
|
||||||
This is an extreme example, and it is totally the opposite of what I mean when I say I am a Lazy SysAdmin and being a Lazy SysAdmin is a good thing.
|
|
||||||
|
|
||||||
#### Real productivity
|
|
||||||
|
|
||||||
I am fortunate to have worked for some true managers—they were people who understood that the productivity of a SysAdmin is not measured by how many hours per day are spent banging on a keyboard. After all, even a monkey can bang on a keyboard, but that is no indication of the value of the results.
|
|
||||||
|
|
||||||
As I say in my book:
|
|
||||||
|
|
||||||
> "I am a lazy SysAdmin and yet I am also a very productive SysAdmin. Those two seemingly contradictory statements are not mutually exclusive, rather they are complementary in a very positive way. …
|
|
||||||
>
|
|
||||||
> "A SysAdmin is most productive when thinking—thinking about how to solve existing problems and about how to avoid future problems; thinking about how to monitor Linux computers in order to find clues that anticipate and foreshadow those future problems; thinking about how to make their work more efficient; thinking about how to automate all of those tasks that need to be performed whether every day or once a year.
|
|
||||||
>
|
|
||||||
> "This contemplative aspect of the SysAdmin job is not well known or understood by those who are not SysAdmins—including many of those who manage the SysAdmins, the Pointy Haired Bosses. SysAdmins all approach the contemplative parts of their job in different ways. Some of the SysAdmins I have known found their best ideas at the beach, cycling, participating in marathons, or climbing rock walls. Others think best when sitting quietly or listening to music. Still others think best while reading fiction, studying unrelated disciplines, or even while learning more about Linux. The point is that we all stimulate our creativity in different ways, and many of those creativity boosters do not involve typing a single keystroke on a keyboard. Our true productivity may be completely invisible to those around the SysAdmin."
|
|
||||||
|
|
||||||
There are some simple secrets to being the Lazy SysAdmin—the SysAdmin who accomplishes everything that needs to be done and more, all the while keeping calm and collected while others are running around in a state of panic. Part of this is working efficiently, and part is about preventing problems in the first place.
|
|
||||||
|
|
||||||
### Ways to be the Lazy SysAdmin
|
|
||||||
|
|
||||||
#### Thinking
|
|
||||||
|
|
||||||
I believe the most important secret about being the Lazy SysAdmin is thinking. As in the excerpt above, great SysAdmins spend a significant amount of time thinking about things we can do to work more efficiently, locate anomalies before they become problems, and work smarter, all while considering how to accomplish all of those things and more.
|
|
||||||
|
|
||||||
For example, right now—in addition to writing this article—I am thinking about a project I intend to start as soon as the new parts arrive from Amazon and the local computer store. The motherboard on one of my less critical computers is going bad, and it has been crashing more frequently recently. But my very old and minimal server—the one that handles my email and external websites, as well as providing DHCP and DNS services for the rest of my network—isn't failing but has to deal with intermittent overloads due to external attacks of various types.
|
|
||||||
|
|
||||||
I started by thinking I would just replace the motherboard and its direct components—memory, CPU, and possibly the power supply—in the failing unit. But after thinking about it for a while, I decided I should put the new components into the server and move the old (but still serviceable) ones from the server into the failing system. This would work and take only an hour, or perhaps two, to remove the old components from the server and install the new ones. Then I could take my time replacing the components in the failing computer. Great. So I started generating a mental list of tasks to do to accomplish this.
|
|
||||||
|
|
||||||
However, as I worked the list, I realized that about the only components of the server I wouldn't replace were the case and the hard drive, and the two computers' cases are almost identical. After having this little revelation, I started thinking about replacing the failing computer's components with the new ones and making it my server. Then, after some testing, I would just need to remove the hard drive from my current server and install it in the case with all the new components, change a couple of network configuration items, change the hostname on the KVM switch port, and change the hostname labels on the case, and it should be good to go. This will produce far less server downtime and significantly less stress for me. Also, if something fails, I can simply move the hard drive back to the original server until I can fix the problem with the new one.
|
|
||||||
|
|
||||||
So now I have created a mental list of the tasks I need to do to accomplish this. And—I hope you were watching closely—my fingers never once touched the keyboard while I was working all of this out in my head. My new mental action plan is low risk and involves a much smaller amount of server downtime compared to my original plan.
|
|
||||||
|
|
||||||
When I worked for IBM, I used to see signs all over that said "THINK" in many languages. Thinking can save time and stress and is the main hallmark of a Lazy SysAdmin.
|
|
||||||
|
|
||||||
#### Doing preventative maintenance
|
|
||||||
|
|
||||||
In the mid-1970s, I was hired as a customer engineer at IBM, and my territory consisted of a fairly large number of [unit record machines][2]. That just means that they were heavily mechanical devices that processed punched cards—a few dated from the 1930s. Because these machines were primarily mechanical, their parts often wore out or became maladjusted. Part of my job was to fix them when they broke. The main part of my job—the most important part—was to prevent them from breaking in the first place. The preventative maintenance was intended to replace worn parts before they broke and to lubricate and adjust the moving components to ensure that they were working properly.
|
|
||||||
|
|
||||||
As I say in The Linux Philosophy for SysAdmins:
|
|
||||||
|
|
||||||
> "My managers at IBM understood that was only the tip of the iceberg; they—and I—knew my job was customer satisfaction. Although that usually meant fixing broken hardware, it also meant reducing the number of times the hardware broke. That was good for the customer because they were more productive when their machines were working. It was good for me because I received far fewer calls from those happier customers. I also got to sleep more due to the resultant fewer emergency off-hours callouts. I was being the Lazy [Customer Engineer]. By doing the extra work upfront, I had to do far less work in the long run.
|
|
||||||
>
|
|
||||||
> "This same tenet has become one of the functional tenets of the Linux Philosophy for SysAdmins. As SysAdmins, our time is best spent doing those tasks that minimize future workloads."
|
|
||||||
|
|
||||||
Looking for problems to fix in a Linux computer is the equivalent of project management. I review the system logs looking for hints of problems that might become critical later. If something appears to be a little amiss, or I notice my workstation or a server is not responding as it should, or if the logs show something unusual—all of these can be indicative of an underlying problem that has not generated symptoms obvious to users or the PHB.
|
|
||||||
|
|
||||||
I do frequent checks of the files in `/var/log/`, especially messages and security. One of my more common problems is the many script kiddies who try various types of attacks on my firewall system. And, no, I do not rely on the alleged firewall in the modem/router provided by my ISP. These logs contain a lot of information about the source of the attempted attack and can be very valuable. But it takes a lot of work to scan the logs on various hosts and put solutions into place. So I turn to automation.
|
|
||||||
|
|
||||||
#### Automating
|
|
||||||
|
|
||||||
I have found that a very large percentage of my work can be performed by some form of automation. One of the tenets of the Linux Philosophy for SysAdmins is "automate everything," and this includes boring, drudge tasks like scanning logfiles every day.
|
|
||||||
|
|
||||||
Programs like [Logwatch][3] can monitor your logfiles for anomalous entries and notify you when they occur. Logwatch usually runs as a cron job once a day and sends an email to root on the localhost. You can run Logwatch from the command line and view the results immediately on your display. Now I just need to look at the Logwatch email notification every day.
|
|
||||||
|
|
||||||
But the reality is just getting a notification is not enough, because we can't sit and watch for problems all the time. Sometimes an immediate response is required. Another program I like, one that does all of the work for me—see, this is the real Lazy Admin—is [Fail2Ban][4]. Fail2Ban scans designated logfiles for various types of hacking and intrusion attempts, and if it sees enough sustained activity of a specific type from a particular IP address, it adds an entry to the firewall that blocks any further hacking attempts from that IP address for a specified time. The defaults tend to be around 10 minutes, but I like to specify 12 or 24 hours for most types of attacks. Each type of hacking attack is configured separately, such as those trying to log in via SSH and those attacking a web server.
|
|
||||||
|
|
||||||
#### Writing scripts
|
|
||||||
|
|
||||||
Automation is one of the key components of the Philosophy. Everything that can be automated should be, and the rest should be automated as much as possible. So, I also write a lot of scripts to solve problems, which also means I write scripts to do most of my work for me.
|
|
||||||
|
|
||||||
My scripts save me huge amounts of time because they contain the commands to perform specific tasks, which significantly reduces the amount of typing I need to do. For example, I frequently restart my email server and my spam-fighting software (which needs restarted when configuration changes are made to SpamAssassin's `local.cf` file). Those services must be stopped and restarted in a specific order. So, I wrote a short script with a few commands and stored it in `/usr/local/bin`, where it is accessible. Now, instead of typing several commands and waiting for each to finish before typing the next one—not to mention remembering the correct sequence of commands and the proper syntax of each—I type in a three-character command and leave the rest to my script.
|
|
||||||
|
|
||||||
#### Reducing typing
|
|
||||||
|
|
||||||
Another way to be the Lazy SysAdmin is to reduce the amount of typing we need to do. Besides, my typing skills are really horrible (that is to say I have none—a few clumsy fingers at best). One possible cause for errors is my poor typing, so I try to keep typing to a minimum.
|
|
||||||
|
|
||||||
The vast majority of GNU and Linux core utilities have very short names. They are, however, names that have some meaning. Tools like `cd` for change directory, `ls` for list (the contents of a directory), and `dd` for disk dump are pretty obvious. Short names mean less typing and fewer opportunities for errors to creep in. I think the short names are usually easier to remember.
|
|
||||||
|
|
||||||
When I write shell scripts, I like to keep the names short but meaningful (to me at least) like `rsbu` for Rsync BackUp. In some cases, I like the names a bit longer, such as `doUpdates` to perform system updates. In the latter case, the longer name makes the script's purpose obvious. This saves time because it's easy to remember the script's name.
|
|
||||||
|
|
||||||
Other methods to reduce typing are command line aliases and command line recall and editing. Aliases are simply substitutions that are made by the Bash shell when you type a command. Type the `alias` command and look at the list of aliases that are configured by default. For example, when you enter the command `ls`, the entry `alias ls='ls –color=auto'` substitutes the longer command, so you only need to type two characters instead of 14 to get a listing with colors. You can also use the `alias` command to add your own aliases.
|
|
||||||
|
|
||||||
Command line recall allows you to use the keyboard's Up and Down arrow keys to scroll through your command history. If you need to use the same command again, you can just press the Enter key when you find the one you need. If you need to change the command once you have found it, you can use standard command line editing features to make the changes.
|
|
||||||
|
|
||||||
### Parting thoughts
|
|
||||||
|
|
||||||
It is actually quite a lot of work being the Lazy SysAdmin. But we work smart, rather than working hard. We spend time exploring the hosts we are responsible for and dealing with any little problems long before they become large problems. We spend a lot of time thinking about the best ways to resolve problems, and we think a lot about discovering new ways to work smarter at being the Lazy SysAdmin.
|
|
||||||
|
|
||||||
There are many other ways to be the Lazy SysAdmin besides the few described here. I'm sure you have some of your own; please share them with the rest of us in the comments.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
如何成为一名懒惰的系统管理员
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Linux 的系统管理员的工作总是复杂的，并且总是伴随这各种陷阱和障碍。从没有足够时间做任何事情，当你想完成那个半秃头老板（PHB）给的任务的时候，他（只会）不停在你的后面.盯着，而最核心的服务器总是在最不合时宜的时间点崩溃，问题和挑战比比皆是。
|
|
||||||
|
|
||||||
（译者注：半秃头老板 [PHB](https://en.wikipedia.org/wiki/Pointy-haired_Boss)，译者：那是[呆伯特漫画](https://zh.wikipedia.org/wiki/%E5%91%86%E4%BC%AF%E7%89%B9)中的角色，缺乏一般知识常识及其职位所应具有的管理能力，爱说大话且富有向物理显示挑战的精神,大概长成这样）
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
我在即将出版的新书 《 The Linux Philosophy for SysAdmins 》（译者注：暂叫《系统管理员的 Liunx 哲学》 ） 中更详细地讨论如何成为一个懒惰的系统管理员，那书预计会在9月出版。这本的部分内容摘录自该书，特别是第九章，「成为一名懒惰的系统管理员」。在我们讨论如何做到这点前，让我们简单了解一下成为一个名懒惰的系统管理员意味着什么。
|
|
||||||
|
|
||||||
### 真实生产力vs.虚假生产力
|
|
||||||
#### 虚假生产力
|
|
||||||
|
|
||||||
在我工作的地方，半秃头老板相信的管理风格叫「走动式管理」（ management by walking around ）。假设某人不在他的键盘上输入东西，或者至少检查他们显示的东西，判断他们的工作是否有效率的。这是一个糟糕的工作场所。它的各部门间有道很高的行政墙，这会造就了许多小型沟通壁垒，大量无用的文书工作，以及获得任何事情的许可都要等待漫长的时间。因为这些或者其他原因，不可能高效地做任何事情 ——如果真的是这样——所以我们是非常低效。为了看起来很忙，我们都有自己的一套 Look Busy 工具包（ Look Busy Kits, LBKs ），可能是一些短小的、用来显示一些行为行为活动的 Bash 脚本，或者是 `top`，`htop`，`iotop` 之类的程序，或者是一些持续显示某些行为活动的监控工具。这个工作场所的风气让人不可能真正高效， 我讨厌这个地方, 也讨厌那个几乎不可能完成任何有价值的事情的事实。
|
|
||||||
|
|
||||||
这糟糕场所对真实的系统管理员来讲是场噩梦。我们中没有人会感到快乐。（在那里）花费四五月才能完成的事，在其他地方只需的一个早晨。我们没有什么实际工作要做，却要花大量的时间干活来（让自己）看起来很忙。我们有一个无言竞赛，创造最好的 LBK（ Look Busy Kits） ，这就是我们花费最多时间的地方了。那份工作我只做了几个月，但好像已经过完一生。如果你看到的这个监狱的表面，你可能会说我们是很懒，因为我们只完成了几乎为 0 的实际工作。
|
|
||||||
|
|
||||||
这是个极端的例子，它完全与我所说的“我是一个懒惰的系统管理员”的意思相反，做一个懒惰的系统管理是件好事。
|
|
||||||
|
|
||||||
#### 真实生产力
|
|
||||||
|
|
||||||
我很幸运，曾为一些真正的经理工作——他们明白，系统管理员的生产力并不是以每天花多少小时敲键盘来衡量。毕竟，即使一只猴子能敲击他们的键盘，但也不能说明结果的价值。
|
|
||||||
|
|
||||||
正如我书中所言
|
|
||||||
|
|
||||||
> 「我是一个懒惰的系统管理员，同时我也是一个高效的系统管理员。这两者看似矛盾的说法不是相互排斥的，而是会以一种非常积极的方式相辅相成。。。
|
|
||||||
>
|
|
||||||
> 「一个系统管理员在思考的时候是最高效的——思考关于如何解决现有问题和避免未来的问题；思考怎样监控 Linux 计算机，以便找到预测和预示这些未来的问题的线索；思考如何让他们的工作更有效率；思考如何自动化所有这些要执行的任务, 无论是每天还是每年一次的任务。
|
|
||||||
>
|
|
||||||
> 「系统管理员冥思苦想的那一面是不会被非系统管理员所熟知的，那些人包括很多掌管着系统管理员的人，比如那个半秃头老板。系统管理员都会以不同的方式解决他们工作中苦思的部分。一些我认识的系统管理员会在沙滩、骑自行车、参加马拉松或者攀岩时找到最好的想法。另一些人会认为静坐或听音乐的时候思考得最好。还有一些会在阅读小说、学习不相关的学科、甚至在学习 Linux 系统的时候会想得最好。关键是我们都有不同的方式激发我们的创造力，而这些创造力的推进器中很多并不涉及键盘上的一个按键。我们真正的生产力对于系统管理员周围的人来说可能是完全看不见的。」
|
|
||||||
|
|
||||||
成为懒惰的系统管理员有一些简单的秘诀——系统管理员要完成一切需要完成的事，而且更多的是，当所有人都处于恐慌的状态时要保持冷静和镇定。（秘诀的）一部分是高效工作，另一部分是把预防问题放在首位。
|
|
||||||
|
|
||||||
### 成为懒惰系统管理员的方法
|
|
||||||
|
|
||||||
#### 多思考
|
|
||||||
|
|
||||||
我相信关于懒惰系统管理员最重要的秘诀在于思考。正如上面的摘录所言，优秀的系统管理员会花大量的时候思考这些事情，如何更有效率地工作，在异常成为问题前如何定位，更聪明地工作，做其他所有东西的同时会考虑如何完成这些的事等等。
|
|
||||||
|
|
||||||
例如，现在——除了撰写本文之外——我正在想一个项目，我打算在新部件从亚马逊和本地计算机商店到达时才开始。 我不那么重要的计算机上的主板坏了，最近它的崩溃更频率。 但我旧的和最小的服务器——处理我的电子邮件和外部网站，以及为我的网络的其余部分提供 DHCP 和 DNS 服务——并没有出现故障，但必须处理由于各种外部攻击而导致的间歇性过载。
|
|
||||||
|
|
||||||
我一开始想，我只要替换故障单元中的主板及其直接部件——内存、CPU，可能还有电源。但是在考虑了一段时间之后，我决定将新部件放到服务器中，并将旧的（但仍然可用的）部件从服务器移到故障系统中。可以这样做的，只需一、两个小时就可以从服务器上移除旧部件并安装新的。然后我就可以花时间更换出故障的电脑里的部件了。太好了。所以我开始在脑海中列出要完成的任务。
|
|
||||||
|
|
||||||
然而，当我查看列表时，我意识到服务器中唯一不能替换的部件是机箱和硬盘驱动器，这两台计算机的机箱几乎完全相同。在有了这个小小的发现之后，我开始考虑用新的部件替换出故障的计算机的部件，并将之作为我的服务器。经过一些测试之后，我只需从当前的服务器移除硬盘，并将它安装到新的组件中，改下网络配置项，再更改 KVM 交换机端口上的主机名，并更改主机名标签，就可以了。这将大大减少服务器停机时间，大大减少我的压力。此外，如果出现故障，我可以简单地将硬盘移回原来的服务器，直到我可以用新服务器解决问题为止。
|
|
||||||
|
|
||||||
所以，现在我在脑海中已经创建了一个我需要做的任务清单，以完成这项工作。而且——我希望你能仔细观察——当我脑子里想着这一切的时候，我的手指从来没有碰过键盘。我新的心理行动计划风险很低，与我最初的计划相比，涉及的服务器停机时间要少得多。
|
|
||||||
|
|
||||||
当我在 IBM 工作的时候，我经常看到很多语言中都有写着“思考”的标语。思考可以节省时间和压力，是懒散的系统管理员的主要标志。
|
|
||||||
|
|
||||||
#### 做预防性维护
|
|
||||||
|
|
||||||
在 1970 年代中期，我被 IBM 聘为客户工程师，我的领地由相当多的穿孔卡片设备组成。这也就是说，它们是处理打孔卡的重型机械设备—— 一些可以追溯到20世纪30年代。因为这些机器主要是机械的，所以它们的部件经常磨损或失调。我的部分工作是在他们损坏时修复这些他们。我工作的主要部分——最重要的部分 ——首先要防止它们。预防性维护的目的是在磨损部件损坏之前进行更换，并对还在运行的部件进行润滑和调整，以确保它们工作正常。
|
|
||||||
|
|
||||||
|
|
||||||
正如我在《系统管理员的 Linux哲学》（ The Linux Philosophy for SysAdmins）中所言：
|
|
||||||
|
|
||||||
>「我在 IBM 的经理们明白这只是冰山一角；他们——和我——都是我的工作是让顾客满意。虽然这通常意味着修复损坏的硬件，但也意味着减少硬件损坏的次数。这对客户来说是好事，因为他们的机器在工作时工作效率更高。这对我有好处，因为我从那些快乐的客户那里接到的电话要少得多。我也睡了更多的觉，因为这样做的结果是更少的非工作时间的紧急电话。我是个懒惰的（客户工程师）。通过提前做额外的工作，从长远来看，我需要做的工作要少得多。
|
|
||||||
>
|
|
||||||
>「这一原则已成为系统管理员的 Linux 哲学的功能原则之一。作为系统管理员，我们的时间最好用在最大限度地减少未来工作量的任务上。」
|
|
||||||
|
|
||||||
在 Linux 计算机中查找要解决的问题相当于项目管理。我检查系统日志，寻找以后可能会变得非常危险的问题的暗示。如果出现了一些小问题，或者我注意到我的工作站、服务器没有做出该有的响应，或者如果日志显示了一些不寻常的东西——所有这些都可以暗示出潜在的问题，而对于用户或半秃头老板来说，这些问题并没有产生明显的症状。
|
|
||||||
|
|
||||||
我经常检查 `/var/log/` 中的文件，特别是 messages 和 security 文件。我最常见的问题之一是许多脚本小子在我的防火墙系统上尝试各种类型的攻击。而且，不，我不依赖 ISP（Internet Service Provider，网络服务提供者）提供的调制解调器/路由器中的所谓的防火墙。这些日志包含了大量关于企图攻击来源的信息，非常有价值。但是要扫描不同主机上的日志并将解决方案部署到位，需要做大量的工作。所以我转向自动化。
|
|
||||||
|
|
||||||
#### 自动化
|
|
||||||
|
|
||||||
我发现我的工作有很大一部分可以通过某种形式的自动化来完成。系统管理员的 Linux 哲学的原则之一是 「自动化一切」，这包括每天扫描日志文件等枯燥乏味的任务。
|
|
||||||
|
|
||||||
像是 [Logwatch][3] 这类的程序能够监控你的日志文件中的异常条目，并在异常条目发生时通知您。Logwatch通常作为 cron jobs（译者注，Linux/Unix 中周期作业程序）每天运行一次，并向本地主机上的 root 用户发送电子邮件。你可以从命令行运行 Logwatch，并立即在显示器上查看结果。现在我只需要每天查看 Logwatch 的电子邮件通知。
|
|
||||||
|
|
||||||
但现实是，仅仅收到通知是不够的，因为我们不能坐以待毙。有时需要立即作出反应。我喜欢的另一个程序是——它能为我做所有事——（让大家看到，这就是懒惰的管理员）——它就是[Fail2ban][4]。Fail2Ban 会扫描指定的日志文件，查找各种类型的黑客攻击和入侵尝试，如果它发现某个 IP 地址在做特定类型的持续活动够了，它会向防火墙添加一个条目，在指定的时间内阻止来自该 IP 地址的任何进一步的黑客尝试。默认值通常在 10 分钟左右，但我喜欢为大多数类型的攻击指定为 12 或 24 小时。每种类型的黑客攻击都是单独配置的，例如尝试通过 SSH 登录和那些 Web 服务器的攻击。
|
|
||||||
|
|
||||||
#### 写脚本
|
|
||||||
|
|
||||||
自动化是哲学的关键组成部分之一。一切可以自动化的东西都应该自动化的，其余的尽可能地自动化。所以，我也写了很多脚本来解决问题，也就说说我编写脚本来完成我的大部分工作。
|
|
||||||
|
|
||||||
我的脚本帮我节省了大量时间，因为它们包含执行特定任务的命令，这大大减少了我需要输入的数量。例如，我经常重新启动我的电子邮件服务器和垃圾邮件处理软件（当修改 SpamAssassin 的 `local.cf` 配置文件时，就需要重启）。必须按特定顺序停止并重新启动这些服务。因此，我用几个命令编写了一个简短的脚本，并将其存储在可访问的 `/usr/local/bin` 中。现在，不用键入几个命令并等待每个命令都完成，然后再键入下一个命令——更用记住正确的命令顺序和每个命令的正确语法——我输入一个三个字符的命令，其余的留给我的脚本来完成。
|
|
||||||
|
|
||||||
#### 简化键入
|
|
||||||
|
|
||||||
另一种成为懒惰的系统管理员的方法是减少我们需要键入的数量。而且，我的打字技巧真的很糟糕（也就是说，我一点也没有——顶多是几个笨拙的手指）。导致错误的一个可能原因是我的打字不好，所以我会尽量少打字。
|
|
||||||
|
|
||||||
绝大多数 GNU 和 Linux 核心实用程序都有非常短的名称。然而，它们都是有意义的名字。诸如用于更改目录的 `cd` 、用于列出（目录内容）的 `ls` 和用于磁盘转储的 `dd` 等工具都非常明显。短名字意味着更少的打字和更少的产生错误机会。我认为短的名字通常更容易记住。
|
|
||||||
|
|
||||||
当我编写 shell 脚本时，我喜欢保持名称简短而意义（至少对我来说是），比如用于 rsync 备份的 `rsbu`（译者注，Rsync Backup 的简写）。在某些情况下，我喜欢使用更长的名称，比如 `doUpdates` 来执行系统更新。在后一种情况下，长一点名让脚本的目的就越明显。这可以节省时间，因为很容易记住脚本的名称。
|
|
||||||
|
|
||||||
其他减少键入的方法包括命令行别名（alias）、命令行调回（recall）和编辑。别名只是你在 Bash shell 键入命令时才做的替换。键入 `alias` 命令会看到默认配置的别名列表。例如，当你输入命令 `ls` 时，会被条目 `alias ls='ls –color=auto'` 替成较长的命令，因此你只需键入 2 个字符而不是 14 个字符即可获得带有颜色的列表。还可以使用 `alias` 命令添加你自己（定义）的别名。
|
|
||||||
|
|
||||||
命令行调回允许你使用键盘的向上和向下箭头键滚动浏览命令历史记录。如果需要再次使用相同的命令，只需在找到所需的命令时按 Enter 键即可。如果在找到命令后需要更改该命令，则可以使用标准命令行编辑功能进行更改。
|
|
||||||
|
|
||||||
### 结束语
|
|
||||||
|
|
||||||
一名懒惰的系统管理员实际上也有很多的工作。但我们是聪明地工作，而不是刻苦工作。早在一堆小问题汇聚成大问题之前, 我们就花时间探索我们负责的主机,并处理好所有的小问题。我们花了很多时间思考解决问题的最佳方法, 我们也花了很多时间来发现新的方法, 让自己更聪明地工作, 成为懒惰的系统管理员。
|
|
||||||
|
|
||||||
除了这里描述的少数方法外, 还有许多其他的方式可以成为懒惰的系统管理员。我相信你也有一些自己的方式;请在评论中和我们分享。
|
|
||||||
|
|
||||||
--------------------------------------------------------------------------------
|
|
||||||
|
|
||||||
via: https://opensource.com/article/18/7/how-be-lazy-sysadmin
|
|
||||||
|
|
||||||
作者：[David Both][a]
|
|
||||||
选题：[lujun9972](https://github.com/lujun9972)
|
|
||||||
译者：[zgj1024](https://github.com/zgj1024)
|
|
||||||
校对：[校对者ID](https://github.com/校对者ID)
|
|
||||||
|
|
||||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
|
||||||
|
|
||||||
[a]:https://opensource.com/users/dboth
|
|
||||||
[1]:https://www.apress.com/us/book/9781484237298
|
|
||||||
[2]:https://en.wikipedia.org/wiki/Unit_record_equipment
|
|
||||||
[3]:https://www.techrepublic.com/article/how-to-install-and-use-logwatch-on-linux/
|
|
||||||
[4]:https://www.fail2ban.org/wiki/index.php/Main_Page
|
|
||||||
@ -0,0 +1,292 @@
|
|||||||
|
[#]: collector: (lujun9972)
|
||||||
|
[#]: translator: (MjSeven)
|
||||||
|
[#]: reviewer: ( )
|
||||||
|
[#]: publisher: ( )
|
||||||
|
[#]: url: ( )
|
||||||
|
[#]: subject: (YAML: probably not so great after all)
|
||||||
|
[#]: via: (https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html)
|
||||||
|
[#]: author: (Martin Tournoij https://arp242.net/)
|
||||||
|
|
||||||
|
YAML: 可能并不是那么完美
|
||||||
|
======
|
||||||
|
|
||||||
|
我之前写过[为什么将 JSON 用于人类可编辑的配置文件是一个坏主意][1]，今天我们将讨论 YAML 格式的一些常见问题。
|
||||||
|
|
||||||
|
### 默认情况下不安全
|
||||||
|
|
||||||
|
YAML 默认是不安全的。加载用户提供的（不可信的）YAML 字符串需要仔细考虑。
|
||||||
|
```
|
||||||
|
!!python/object/apply:os.system
|
||||||
|
args: ['ls /']
|
||||||
|
```
|
||||||
|
|
||||||
|
用 `print(yaml.load(open('a.yaml')))` 运行它，应该给你这样的东西：
|
||||||
|
```
|
||||||
|
bin etc lib lost+found opt root sbin tmp var sys
|
||||||
|
boot dev efi home lib64 mnt proc run srv usr
|
||||||
|
0
|
||||||
|
```
|
||||||
|
|
||||||
|
许多其他语言（包括 Ruby 和 PHP）默认情况下（to 校正：这里应该说的是解析 yaml）也不安全。[在 GitHub 上搜索 `yaml.load`][2] 会得到惊人的 280 万个结果，而 [`yaml.safe_load`][3] 只能得到 26,000 个结果。
|
||||||
|
|
||||||
|
提个醒，很多这样的 `yaml.load()` 都工作的很好，在配置文件中加载 `yaml.load()` 通常没问题，因为它通常（虽然并不总是！）来自“可靠源”，而且很多都来自静态的 YAML 测试文件。但是，人们还是不禁怀疑在这 280 万个结果中隐藏了多少漏洞。
|
||||||
|
|
||||||
|
这不是一个理论问题。在 2013 年，[正是由于这个问题，所有的 Ruby on Rails 应用程序都被发现易受][4]远程代码执行攻击。
|
||||||
|
|
||||||
|
有人可能会反驳说这不是 YAML 格式的错误，而是那些库实现错误的的问题，但似乎大多数库默认不是安全的（特别是动态语言），所以事实上这是 YAML 的一个问题。
|
||||||
|
|
||||||
|
有些人可能会反驳认为修复它就像用 `safe_load()` 替换 `load()` 一样容易，但是很多人都没有意识到这个问题，即使你知道它，它也是很容易忘记的事情之一。这是非常糟糕的 API 设计。
|
||||||
|
|
||||||
|
### 可能很难编辑，特别是对于大文件
|
||||||
|
|
||||||
|
YAML 文件可能很难编辑，随着文件变大，这个难度会快速增大。
|
||||||
|
|
||||||
|
一个很好的例子是 Ruby on Rails 的翻译文件。（to 校正：这里 translation files 是什么？）例如：
|
||||||
|
```
|
||||||
|
en:
|
||||||
|
formtastic:
|
||||||
|
labels:
|
||||||
|
title: "Title" # Default global value
|
||||||
|
article:
|
||||||
|
body: "Article content"
|
||||||
|
post:
|
||||||
|
new:
|
||||||
|
title: "Choose a title..."
|
||||||
|
body: "Write something..."
|
||||||
|
edit:
|
||||||
|
title: "Edit title"
|
||||||
|
body: "Edit body"
|
||||||
|
```
|
||||||
|
|
||||||
|
看起来不错，对吧？但是如果这个文件有 100 行怎么办？或者 1,000 行？在文件中很难看到 "where"，因为它可能在屏幕外。你需要向上滚动，但是你需要跟踪缩进，即使使用缩进指南也很难，特别是因为 2 个缩进是常态而且 [tab 缩进被禁止][5]。
|
||||||
|
|
||||||
|
不小心缩进出错通常不是一个错误，它通常只是反序列化为你不想要的东西。这样只能祝你调试快乐！
|
||||||
|
|
||||||
|
我已经愉快地编写 Python 长达十多年，所以我已经习惯了显著的空白，但有时候我仍在和 YAML 抗争。在 Python 中，缺点和清晰度的丧失是由于没有那种长达几页的函数，但数据或配置文件的长度没有这种自然限制。（to 校正：这里不太明白为什么没有长达几页函数会导致 python 清晰度的丧失，或许我的翻译有问题）
|
||||||
|
|
||||||
|
对于小文件，这不是问题，但它确实无法很好地扩展到较大的文件，特别是如果你以后想编辑它们的话。
|
||||||
|
|
||||||
|
### 这非常复杂
|
||||||
|
|
||||||
|
在浏览一个基本的例子时，YAML 看似“简单”和“显而易见”，但事实证明并非如此。[YAML 规范][6]有 23,449 个单词，为了比较，[TOML][7] 有 3,339 个单词，[Json][8] 有 1,969 个单词，[XML][9] 有 20,603 个单词。
|
||||||
|
|
||||||
|
我们中有谁读过全部吗？有谁读过并理解了全部？谁阅读过，理解进而**记住**所有这些？
|
||||||
|
|
||||||
|
例如，你知道有[ 9 种方法在 YAML 中编写多行字符串][10]吗？并且它们具有细微的不同行为。
|
||||||
|
|
||||||
|
是的 :-/
|
||||||
|
|
||||||
|
如果你看一下[它的修订历史][11]，那篇文章就会变得更加有趣，因为文章的作者发现了越来越多的方法可以实现这一点，以及更多的细微之处。
|
||||||
|
|
||||||
|
它从预览开始告诉我们 YANL 规范，它表明（强调我的）：
|
||||||
|
|
||||||
|
> 本节简要介绍了 YAML 的表达能力。**初次阅读的人不可能熟读所有的例子**。相反，这些选择用作规范其余部分的动机。
|
||||||
|
|
||||||
|
#### 惊讶的行为
|
||||||
|
|
||||||
|
以下会解析成什么（[Colm O’Connor][12] 提供的例子）：
|
||||||
|
```
|
||||||
|
- Don Corleone: Do you have faith in my judgment?
|
||||||
|
- Clemenza: Yes
|
||||||
|
- Don Corleone: Do I have your loyalty?
|
||||||
|
```
|
||||||
|
|
||||||
|
结果为
|
||||||
|
```
|
||||||
|
[
|
||||||
|
{'Don Corleone': 'Do you have faith in my judgment?'},
|
||||||
|
{'Clemenza': True},
|
||||||
|
{'Don Corleone': 'Do I have your loyalty?'}
|
||||||
|
]
|
||||||
|
```
|
||||||
|
|
||||||
|
那么这个呢：
|
||||||
|
```
|
||||||
|
python: 3.5.3
|
||||||
|
postgres: 9.3
|
||||||
|
```
|
||||||
|
|
||||||
|
`3.5.3` 被识别为字符串，但 `9.3` 被识别为数字而不是字符串：
|
||||||
|
```
|
||||||
|
{'python': '3.5.3', 'postgres': 9.3}
|
||||||
|
```
|
||||||
|
|
||||||
|
这个呢：
|
||||||
|
```
|
||||||
|
Effenaar: Eindhoven
|
||||||
|
013: Tilburg
|
||||||
|
```
|
||||||
|
|
||||||
|
013 是蒂尔堡(Tilburg)的一个流行音乐场地，但 YAML 会告诉你错误答案，因为它被解析为八进制数字：
|
||||||
|
```
|
||||||
|
{11: 'Tilburg', 'Effenaar': 'Eindhoven'}
|
||||||
|
```
|
||||||
|
|
||||||
|
所有这一切，以及更多，就是为什么许多经验丰富的 YAMLers 经常会引用所有字符串的原因，即使它不是严格要求。许多人不使用引号，而且很容易忘记，特别是如果文件的其余部分（可能由其他人编写）不使用引号。
|
||||||
|
|
||||||
|
### 它不方便
|
||||||
|
|
||||||
|
因为它太复杂了，它声称的可移植性被夸大了。例如，考虑以下这个从 YAML 规范中获取的示例：
|
||||||
|
```
|
||||||
|
? - Detroit Tigers
|
||||||
|
- Chicago cubs
|
||||||
|
:
|
||||||
|
- 2001-07-23
|
||||||
|
|
||||||
|
? [ New York Yankees,
|
||||||
|
Atlanta Braves ]
|
||||||
|
: [ 2001-07-02, 2001-08-12,
|
||||||
|
2001-08-14 ]
|
||||||
|
```
|
||||||
|
|
||||||
|
除了大多数读者可能甚至不知道这样做的事实，还可以尝试使用 PyYAML 在 Python 中解析它：
|
||||||
|
```
|
||||||
|
yaml.constructor.ConstructorError: while constructing a mapping
|
||||||
|
in "a.yaml", line 1, column 1
|
||||||
|
found unhashable key
|
||||||
|
in "a.yaml", line 1, column 3
|
||||||
|
```
|
||||||
|
|
||||||
|
在 Ruby 中，它可以工作：
|
||||||
|
```
|
||||||
|
{
|
||||||
|
["Detroit Tigers", "Chicago cubs"] => [
|
||||||
|
#<Date: 2001-07-23 ((2452114j,0s,0n),+0s,2299161j)>
|
||||||
|
],
|
||||||
|
["New York Yankees", "Atlanta Braves"] => [
|
||||||
|
#<Date: 2001-07-02 ((2452093j,0s,0n),+0s,2299161j)>,
|
||||||
|
#<Date: 2001-08-12 ((2452134j,0s,0n),+0s,2299161j)>,
|
||||||
|
#<Date: 2001-08-14 ((2452136j,0s,0n),+0s,2299161j)>
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
原因是你不能在 Python 中使用列表作为一个字典(dict)键：
|
||||||
|
```
|
||||||
|
>>> {['a']: 'zxc'}
|
||||||
|
Traceback (most recent call last):
|
||||||
|
File "<stdin>", line 1, in <module>
|
||||||
|
TypeError: unhashable type: 'list'
|
||||||
|
```
|
||||||
|
|
||||||
|
而这种限制并不是 Python 特有的，PHP, JavaScript 和 Go 等常用语言都有此限制。
|
||||||
|
|
||||||
|
因此，在 YAML 文件中使用它，你将无法在大多数语言中解析它。
|
||||||
|
|
||||||
|
这是另一个从 YAML 规范的示例部分中获取的：
|
||||||
|
```
|
||||||
|
# Ranking of 1998 home runs
|
||||||
|
---
|
||||||
|
- Mark McGwire
|
||||||
|
- Sammy Sosa
|
||||||
|
- Ken Griffey
|
||||||
|
|
||||||
|
# Team ranking
|
||||||
|
---
|
||||||
|
- Chicago Cubs
|
||||||
|
- St Louis Cardinals
|
||||||
|
```
|
||||||
|
|
||||||
|
Python 会输出：
|
||||||
|
|
||||||
|
```
|
||||||
|
yaml.composer.ComposerError: expected a single document in the stream
|
||||||
|
in "a.yaml", line 3, column 1
|
||||||
|
but found another document
|
||||||
|
in "a.yaml", line 8, column 1
|
||||||
|
```
|
||||||
|
|
||||||
|
然而 Ruby 输出：
|
||||||
|
```
|
||||||
|
["Mark McGwire", "Sammy Sosa", "Ken Griffey"]
|
||||||
|
```
|
||||||
|
|
||||||
|
原因是单个文件中有多个 YAML 文档（`---` 意味开始一个新文档）。在 Python 中，有一个 `load_all` 函数来解析所有文档，而 Ruby 的 `load()` 只是加载第一个文档，据我所知，它没有办法加载多个文档。
|
||||||
|
|
||||||
|
[在实现之间存在很多不兼容][13]。
|
||||||
|
|
||||||
|
### 目标实现了吗？
|
||||||
|
|
||||||
|
规范说明：
|
||||||
|
|
||||||
|
> YAML 的设计目标是降低优先级：
|
||||||
|
>
|
||||||
|
> 1. YAML 很容易被人类阅读。
|
||||||
|
> 2. YAML 数据在编程语言之间是可移植的。
|
||||||
|
> 3. YAML 匹配敏捷语言的原生数据结构。
|
||||||
|
> 4. YAML 有一个一致的模型来支持通用工具。
|
||||||
|
> 5. YAML 支持一趟处理。(to 校正：这里 one-pass 是否有专业翻译？)
|
||||||
|
> 6. YAML 具有表现力和可扩展性。
|
||||||
|
> 7. YAML 易于实现和使用。
|
||||||
|
>
|
||||||
|
|
||||||
|
那么它有多好呢？
|
||||||
|
|
||||||
|
> YAML 很容易被人类阅读。
|
||||||
|
只有坚持一小部分时才有效。完整集很复杂 - 远远超过 XML 或 JSON。
|
||||||
|
|
||||||
|
> YAML 数据在编程语言之间是可移植的。
|
||||||
|
事实并非如此，因为创建常见语言不支持的结构太容易了。
|
||||||
|
|
||||||
|
> YAML 匹配敏捷语言的原生数据结构。
|
||||||
|
往上看。另外，为什么只支持敏捷（或动态）语言？其他语言呢？
|
||||||
|
|
||||||
|
> YAML 有一个一致的模型来支持通用工具。
|
||||||
|
我甚至不确定这意味着什么，我找不到任何详细说明。
|
||||||
|
|
||||||
|
> YAML 支持一趟处理。
|
||||||
|
这点我接受。
|
||||||
|
|
||||||
|
> YAML 具有表现力和可扩展性。
|
||||||
|
嗯，是的，但它太富有表现力（例如太复杂）。
|
||||||
|
|
||||||
|
> YAML 易于实现和使用。
|
||||||
|
```
|
||||||
|
$ cat `ls -1 ~/gocode/src/github.com/go-yaml/yaml/*.go | grep -v _test` | wc -l
|
||||||
|
9247
|
||||||
|
|
||||||
|
$ cat /usr/lib/python3.5/site-packages/yaml/*.py | wc -l
|
||||||
|
5713
|
||||||
|
```
|
||||||
|
|
||||||
|
### 结论
|
||||||
|
|
||||||
|
不要误解我的意思，并不是说 YAML 很糟糕 - 它肯定不像[使用 JSON 那么多的问题][1] - 但它也不是非常好。有一些一开始并不明显的缺点和惊喜，还有许多更好的替代品，如 [TOML][7] 和其他更专业的格式。
|
||||||
|
|
||||||
|
就个人而言，当我有选择时，我不太可能再次使用它。
|
||||||
|
|
||||||
|
如果你必须使用 YAML，那么我建议你使用 [StrictYAML][14]，它会删除一些（虽然不是全部）比较麻烦的部分。
|
||||||
|
|
||||||
|
### 反馈
|
||||||
|
|
||||||
|
你可以发送电子邮件至 [martin@arp242.net][15] 或[创建 GitHub issue][16] 以获取反馈，问题等。
|
||||||
|
|
||||||
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
via: https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html
|
||||||
|
|
||||||
|
作者：[Martin Tournoij][a]
|
||||||
|
选题：[lujun9972][b]
|
||||||
|
译者：[MjSeven](https://github.com/MjSeven)
|
||||||
|
校对：[校对者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://arp242.net/weblog/JSON_as_configuration_files-_please_dont.html
|
||||||
|
[2]: https://github.com/search?q=yaml.load&type=Code&utf8=%E2%9C%93
|
||||||
|
[3]: https://github.com/search?q=yaml.safe_load&type=Code&utf8=%E2%9C%93
|
||||||
|
[4]: https://www.sitepoint.com/anatomy-of-an-exploit-an-in-depth-look-at-the-rails-yaml-vulnerability/
|
||||||
|
[5]: http://www.yaml.org/faq.html
|
||||||
|
[6]: http://yaml.org/spec/1.2/spec.pdf
|
||||||
|
[7]: https://github.com/toml-lang/toml
|
||||||
|
[8]: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
|
||||||
|
[9]: https://www.w3.org/TR/REC-xml/
|
||||||
|
[10]: http://stackoverflow.com/a/21699210/660921
|
||||||
|
[11]: http://stackoverflow.com/posts/21699210/revisions
|
||||||
|
[12]: https://github.com/crdoconnor/strictyaml/blob/master/FAQ.rst#what-is-wrong-with-implicit-typing
|
||||||
|
[13]: https://github.com/cblp/yaml-sucks
|
||||||
|
[14]: https://github.com/crdoconnor/strictyaml
|
||||||
|
[15]: mailto:martin@arp242.net
|
||||||
|
[16]: https://github.com/Carpetsmoker/arp242.net/issues/new
|
||||||
Loading…
Reference in New Issue
Block a user