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

Merge remote-tracking branch 'LCTT/master'

Browse Source
This commit is contained in:
Xingyu Wang 2019-08-07 21:22:51 +08:00
commit e729c631ed
5 changed files with 213 additions and 219 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
translated/tech/20190801 5 Free Partition Managers for Linux.md → published/20190801 5 Free Partition Managers for Linux.md
View File

@ -1,8 +1,8 @@
[#]: collector: (lujun9972)
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: reviewer: (wxy)
[#]: publisher: (wxy)
[#]: url: (https://linux.cn/article-11196-1.html)
[#]: subject: (5 Free Partition Managers for Linux)
[#]: via: (https://itsfoss.com/partition-managers-linux/)
[#]: author: (Ankush Das https://itsfoss.com/author/ankush/)
@ -10,16 +10,17 @@
5 个免费的 Linux 分区管理器
======
_ **以下是我们推荐的 Linux 分区工具。它们能让你删除、添加、微调 Linux 系统上的磁盘分区或分区大小。** _
> 以下是我们推荐的 Linux 分区工具。它们能让你删除、添加、调整或缩放 Linux 系统上的磁盘分区。
通常，你在安装操作系统时决定磁盘分区。但是，如果你需要在安装后的某个时间修改分区，该怎么办？你无法会到系统安装页面。因此，这就需要分区管理器（或准确地说是磁盘分区管理器）上场了。
通常，你在安装操作系统时决定磁盘分区。但是，如果你需要在安装后的某个时间修改分区，该怎么办？你无法回到系统安装阶段。因此，这就需要分区管理器（或准确地说是磁盘分区管理器）上场了。
在大多数情况下，你无需单独安装分区管理器，因为它已预先安装。此外，值得注意的是，你可以选择基于命令行或有 GUI 的分区管理器。
注意！
**注意！**
磁盘分区是一项有风险的任务。除非绝对必要，否则不要这样做。
如果你使用的是基于命令行的分区工具，那么需要学习完成任务的命令。否则，你可能最终会擦除整个磁盘。
> 磁盘分区是一项有风险的任务。除非绝对必要，否则不要这样做。
>
> 如果你使用的是基于命令行的分区工具，那么需要学习完成任务的命令。否则，你可能最终会擦除整个磁盘。
### Linux 中的 5 个管理磁盘分区的工具
@ -35,7 +36,7 @@ _ **以下是我们推荐的 Linux 分区工具。它们能让你删除、添加
它会在启动时直接提示你以 root 用户进行身份验证。所以，你根本不需要在这里使用终端。身份验证后，它会分析设备，然后让你调整磁盘分区。如果发生数据丢失或意外删除文件，你还可以找到“尝试数据救援”的选项。
[GParted][3]
- [GParted][3]
#### GNOME Disks
@ -43,36 +44,35 @@ _ **以下是我们推荐的 Linux 分区工具。它们能让你删除、添加
一个基于 GUI 的分区管理器，随 Ubuntu 或任何基于 Ubuntu 的发行版（如 Zorin OS）一起出现。
它能让你删除、添加、调整大小和微调分区。如果还有疑问，它甚至可以帮助你[在 Ubuntu 中格式化 USB][6]。
它能让你删除、添加、缩放和微调分区。如果你遇到故障，它甚至可以[在 Ubuntu 中格式化 USB][6] 来帮助你救援机器。
你甚至可以借助此工具尝试修复分区。它的选项还包括编辑文件系统、创建分区镜像、还原镜像以及对分区进行基准测试。
[GNOME Disks][7]
- [GNOME Disks][7]
#### KDE Partition Manager
![Kde Partition Manager][8]
KDE Partition Manager 应该预装在基于 KDE 的 Linux 发行版上。但是，如果没有，你可以在软件中心搜索并轻松安装它。
KDE Partition Manager 应该已经预装在基于 KDE 的 Linux 发行版上了。但是，如果没有，你可以在软件中心搜索并轻松安装它。
如果你没有预装它，那么可能会在尝试启动时通知你没有管理权限。没有管理员权限，你无法做任何事情。因此，在这种情况下，请输入以下命令：
如果你不是预装的，那么可能会在尝试启动时通知你没有管理权限。没有管理员权限，你无法做任何事情。因此，在这种情况下，请输入以下命令：
```
sudo partitionmanager
```
它将扫描你的设备，然后你就可以创建、移动、复制、删除和调整分区大小。你还可以导入/导出分区表及使用其他许多调整选项。
它将扫描你的设备，然后你就可以创建、移动、复制、删除和缩放分区。你还可以导入/导出分区表及使用其他许多调整选项。
[KDE Partition Manager][9]
- [KDE Partition Manager][9]
#### Fdisk （命令行）
#### Fdisk（命令行）
![Fdisk][10]
[fdisk][11] 是一个命令行程序，它在每个类 Unix 的系统中都有。不要担心，即使它需要你启动终端并输入命令，但这并不是很困难。但是，如果你在使用基于文本的程序时感到困惑，那么你应该继续使用上面提到的 GUI 程序。它们都做同样的事情。
要启动 fdisk，你必须是 root 用户并指定管理分区的设备。以下是该命令的示例：
要启动 `fdisk`，你必须是 root 用户并指定管理分区的设备。以下是该命令的示例：
```
sudo fdisk /dev/sdc
@ -80,17 +80,17 @@ sudo fdisk /dev/sdc
你可以参考 [Linux 文档项目的维基页面][12]以获取命令列表以及有关其工作原理的更多详细信息。
#### GNU Parted （命令行）
#### GNU Parted（命令行）
![Gnu Parted][13]
这是另一个在你 Linux 发行版上预安装的命令行程序。你需要输入下面的命令启动：
这是在你 Linux 发行版上预安装的另一个命令行程序。你需要输入下面的命令启动：
```
sudo parted
```
**总结**
### 总结
我不会忘了说 [QtParted][15] 是分区管理器的替代品之一。但它已经几年没有维护，因此我不建议使用它。
@ -103,7 +103,7 @@ via: https://itsfoss.com/partition-managers-linux/
作者：[Ankush Das][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/) 荣誉推出

178
sources/tech/20171113 IT disaster recovery- Sysadmins vs. natural disasters - HPE.md
View File

@ -1,178 +0,0 @@
0x996 is translating
IT disaster recovery: Sysadmins vs. natural disasters | HPE
======
![](https://www.hpe.com/content/dam/hpe/insights/articles/2017/11/it-disaster-recovery-sysadmins-vs-natural-disasters/featuredStory/Sysadmins-vs-natural-disasters-1740.jpg.transform/nxt-1043x496-crop/image.jpeg)
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/

2
sources/tech/20190805 4 cool new projects to try in COPR for August 2019.md
View File

@ -1,5 +1,5 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )

172
translated/tech/20171113 IT disaster recovery- Sysadmins vs. natural disasters - HPE.md Normal file
View File

@ -0,0 +1,172 @@
IT 灾备：系统管理员对抗自然灾害 | HPE
======
![](https://www.hpe.com/content/dam/hpe/insights/articles/2017/11/it-disaster-recovery-sysadmins-vs-natural-disasters/featuredStory/Sysadmins-vs-natural-disasters-1740.jpg.transform/nxt-1043x496-crop/image.jpeg)
面对倾泻的洪水或地震时业务需要继续运转。在飓风卡特里娜、桑迪和其他灾难中幸存下来的系统管理员向在紧急状况下负责 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/

36
sources/tech/20190801 Bash Script to Send a Mail When a New User Account is Created in System.md → translated/tech/20190801 Bash Script to Send a Mail When a New User Account is Created in System.md
View File

@ -7,34 +7,34 @@
[#]: via: (https://www.2daygeek.com/linux-bash-script-to-monitor-user-creation-send-email/)
[#]: author: (Magesh Maruthamuthu https://www.2daygeek.com/author/magesh/)
Bash Script to Send a Mail When a New User Account is Created in System
在系统创建新用户时发送邮件的 Bash 脚本
======
There are many open source monitoring tools are currently available in market to monitor Linux systems performance.
目前市场上有许多开源监测工具可用于监控 Linux 系统的性能。
It will send an email alert when the system reaches the specified threshold limit.
当系统到达指定的阈值时，它将发送邮件提醒。
It monitors everything such as CPU utilization, Memory utilization, swap utilization, disk space utilization and much more.
它会监控 CPU 利用率、内存利用率、交换内存利用率、磁盘空间利用率等所有内容。
But i don’t think they have an option to monitor a new user creation activity and alert when it’s happening.
但我不认为他们可以选择监控新用户创建活动，并发送提醒。
If not, it doesn’t really matter as we can write our own bash script to achieve this.
如果没有，这并不重要，因为我们可以编写自己的 bash 脚本来实现这一点。
We had added many useful shell scripts in the past. If you want to check those, navigate to the below link.
我们过去写了许多有用的 shell 脚本。如果要查看它们，请点击以下链接。
* **[How to automate day to day activities using shell scripts?][1]**
* **[如何使用 shell 脚本自动化执行日常任务？][1]**
What the script does? It monitors **`/var/log/secure`**` ` file and alert admin when a new account is created in system.
脚本做了什么？它监测 **`/var/log/secure`** 文件，并在系统创建新帐户时提醒管理员。
We can’t run this script frequently since user creation is not happening very often. However, I’m planning to run this script once in a day.
我们不会经常运行此脚本，因为创建用户不经常发生。但是，我打算一天运行一次这个脚本。
So, that we can get a consolidated report about the user creation.
因此，我们可以获得有关用户创建的综合报告。
If useradd string was found in “/var/log/secure” file for yesterday’s date, then the script will send an email alert to given email id with new users details.
如果在昨天的 “/var/log/secure” 中找到了 useradd 字符串，那么该脚本将向指定的邮箱发送邮件提醒，其中包含了新用户的详细信息。
**Note:** You need to change the email id instead of ours.
**注意：**你需要更改邮箱而不是使用我们的邮箱。
```
# vi /opt/scripts/new-user.sh
@ -77,13 +77,13 @@ rm $MESSAGE
fi
```
Set an executable permission to **`new-user.sh`**` ` file.
给 **`new-user.sh`** 添加可执行权限。
```
$ chmod +x /opt/scripts/new-user.sh
```
Finally add a cronjob to automate this. It will run everyday at 7'o clock.
最后添加一个 cron 任务来自动化执行它。它会在每天 7 点运行。
```
# crontab -e
@ -91,9 +91,9 @@ Finally add a cronjob to automate this. It will run everyday at 7'o clock.
0 7 * * * /bin/bash /opt/scripts/new-user.sh
```
Note: You will be getting an email alert everyday at 7 o'clock, which is for yesterday's log.
注意：你将在每天 7 点收到一封邮件提醒，但这是昨天的日志。
**`Output:`**` ` You will be getting an email alert similar to below.
你将会看到类似下面的邮件提醒。
```
# cat /tmp/logs.txt
@ -113,7 +113,7 @@ via: https://www.2daygeek.com/linux-bash-script-to-monitor-user-creation-send-em
作者：[Magesh Maruthamuthu][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
译者：[geekpi](https://github.com/geekpi)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出