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
5aae303393
@ -1,38 +1,43 @@
|
||||
在 Linux 下交换 Ctrl 与 Caps Lock 键
|
||||
在 Linux 下交换 Ctrl 与大写锁定键
|
||||
======
|
||||
|
||||
Linux 桌面环境使你可以根据需要轻松设置键盘。下面来演示如何去做。
|
||||
> Linux 桌面环境使你可以根据需要轻松设置键盘。下面来演示如何去做。
|
||||
|
||||
|
||||
|
||||
对于许多使用计算机很多年的用户来说，自从第一批 PC 键盘从生产线上下线后不久，Ctrl 和 Caps Lock 键就已经在错误的位置上了。对我来说，这张 1995 年 Sun 工作站的老式键盘照片上的两个键的位置才是正确的。（原谅我放了一张模糊的图片，它是在昏暗的光线下使用 Minox 间谍相机拍摄的。）
|
||||
对于许多使用计算机很多年的用户来说，自从第一批 PC 键盘从生产线上下线后不久，Ctrl 和大写锁定键就已经在错误的位置上了。对我来说，这张 1995 年 Sun 工作站的老式键盘照片上的两个键的位置才是正确的。（原谅我放了一张模糊的图片，它是在昏暗的光线下使用 Minox 间谍相机拍摄的。）
|
||||
|
||||
感兴趣的话，可以读一下维基百科上对于 [Ctrl 键位置的历史][1] 的介绍。我不打算讨论将 Ctrl 键放在“a”旁边而不是 Shift 键下方的各种理由，不评论 Caps Lock 键的无用性，也没有打算与那些主张使用手掌根来触发 Ctrl 键的人争论，即使在一些笔记本电脑键盘上也不可能这样做，因为有的键会位于腕托以下。
|
||||
|
||||
|
||||
相反，我将假设我不是唯一喜欢把 Ctrl 键放在“a”旁边的人，并说明如何使用 Linux 自带的灵活性在各种桌面环境中交换 Ctrl 和 Caps Lock 键的位置。请注意，下面的演示可能只有有限的有效期，因为调整桌面设置的方法经常发生变化，但我希望这为你开了一个好头。
|
||||
感兴趣的话，可以读一下维基百科上对于 [Ctrl 键位置的历史][1] 的介绍。我不打算讨论将 Ctrl 键放在“a”旁边而不是 Shift 键下方的各种理由，也不评论大写锁定键的无用性，也没有打算与那些主张使用手掌根来触发 Ctrl 键的人争论，即使在一些笔记本电脑键盘上不可能这样做到，因为有的键会位于腕托以下。
|
||||
|
||||
相反，我将假设我不是唯一喜欢把 Ctrl 键放在“a”旁边的人，并说明如何使用 Linux 自带的灵活性在各种桌面环境中交换 Ctrl 和大写锁定键的位置。请注意，下面的演示可能只有有限的有效期，因为调整桌面设置的方法经常发生变化，但我希望这为你开了一个好头。
|
||||
|
||||
### GNOME 3
|
||||
|
||||
[GNOME 3][2] 桌面环境用户可以使用 [Tweaks][3] 工具交换 Caps Lock 和 Ctrl 键，如下所示。
|
||||
[GNOME 3][2] 桌面环境用户可以使用 [Tweaks][3] 工具交换大写锁定和 Ctrl 键，如下所示。
|
||||
|
||||
|
||||
|
||||
具体步骤如下：
|
||||
|
||||
1. 从你的 Linux 发行版的软件仓库安装 Tweaks 工具。
|
||||
2. 启动 Tweaks 程序。
|
||||
3. 从左侧菜单中选择“Keyboard & Mouse”。
|
||||
4. 单击“Additional Layout Options”。
|
||||
5. 在打开的窗口中单击“Ctrl position”，然后选择“Swap Ctrl and Caps Lock”。
|
||||
3. 从左侧菜单中选择 “Keyboard & Mouse”。
|
||||
4. 单击 “Additional Layout Options”。
|
||||
5. 在打开的窗口中单击 “Ctrl position”，然后选择 “Swap Ctrl and Caps Lock”。
|
||||
|
||||
完成！顺便说一句，你可以使用 Tweaks 工具做很多很酷的事情。例如，我将我的右 Ctrl 键设置为 Compose 键，这让我可以使用键盘快捷键打出各种字符，例如通过 `Compose+c+,`、`Compose+e+'`、`Compose+O+^` 以及 `Compose+n+~` 分别键入 ç、é、ô 和 ñ。
|
||||
完成！顺便说一句，你可以使用 Tweaks 工具做很多很酷的事情。例如，我将我的右 Ctrl 键设置为 Compose 键，这让我可以使用键盘快捷键打出各种字符，例如通过 `Compose+c+,`、`Compose+e+'`、`Compose+o+^` 以及 `Compose+n+~` 分别键入 ç、é、ô 和 ñ。（LCTT 译注：可参考 [Special characters listed by extended compose sequence](https://www.ibm.com/support/knowledgecenter/en/SSKTWP_9.0.0/com.ibm.notes900.help.doc/acc_spec_characters_r.html)）
|
||||
|
||||
### KDE
|
||||
|
||||
我不使用 [KDE][4]，但我的同事 Seth Kenlon 写的 [KDE tweaks that will change your life][5] 这篇文章的第 5 项演示了如何重新映射按键。
|
||||
我不使用 [KDE][4]，但我的同事 Seth Kenlon 写的 [将改变你的生命的 KDE tweaks][5] 这篇文章的第 5 项演示了如何重新映射按键。
|
||||
|
||||
### Xfce
|
||||
|
||||
据我所知，[Xfce][6] 桌面环境没有一个方便的工具来管理这些（指交换按键）设置。 但是，`setxkbmap` 命令的 `ctrl:swapcaps` 选项可以帮助你完成交换按键的修改。这个修改包含两部分：
|
||||
|
||||
1. 弄清楚命令的用法;
|
||||
1. 弄清楚命令的用法；
|
||||
2. 找出调用命令的位置，以便在桌面启动时激活它。
|
||||
|
||||
第一部分非常简单，命令是：
|
||||
@ -43,7 +48,7 @@ Linux 桌面环境使你可以根据需要轻松设置键盘。下面来演示
|
||||
|
||||
在终端窗口中执行此命令，以确保结果符合你的预期。
|
||||
|
||||
假设上述命令有效，应该在哪里调用此命令呢？这需要一些实验。一种可能是在用户主目录的 `.profile` 文件中；另一个可能是将命令添加到 Xfce 的自启动配置（在设置管理器中查找“Session and Startup”）里。
|
||||
假设上述命令有效，应该在哪里调用此命令呢？这需要一些实验。一种可能是在用户主目录的 `.profile` 文件中；另一个可能是将命令添加到 Xfce 的自启动配置（在设置管理器中查找 “Session and Startup”）里。
|
||||
|
||||
还有一种可能性是在文件 `/etc/default/keyboard` 中使用相同的选项，最终可能看起来像这样：
|
||||
|
||||
@ -76,7 +81,7 @@ BACKSPACE="guess"
|
||||
|
||||
### 其他环境
|
||||
|
||||
最后，上面 StackExchange 的链接中提到的这一点值得强调--配置控制台与配置终端窗口不同；如前所述，后者是通过桌面管理器进行配置的。
|
||||
最后，上面 StackExchange 的链接中提到的这一点值得强调 —— 配置控制台与配置终端窗口不同；如前所述，后者是通过桌面管理器进行配置的。
|
||||
|
||||
`setxkbmap`、`xkeyboard-config`、`keyboard`、`console-setup` 和 `setupcon` 命令的手册都是有用的参考资料。或者，如果你不喜欢阅读手册，可以看一下 [这篇极好的文章][13]。
|
||||
|
||||
@ -87,7 +92,7 @@ via: https://opensource.com/article/18/11/how-swap-ctrl-and-caps-lock-your-keybo
|
||||
作者：[Chris Hermansen][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[jlztan](https://github.com/jlztan)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,50 +1,50 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: subject: (Drive a locomotive through your Linux terminal)
|
||||
[#]: via: (https://opensource.com/article/18/12/linux-toy-sl)
|
||||
[#]: author: (Jason Baker https://opensource.com/users/jason-baker)
|
||||
[#]: url: ( )
|
||||
[#]: url: (https://linux.cn/article-10357-1.html)
|
||||
|
||||
在 Linux 终端中开火车
|
||||
======
|
||||
使用 sl 命令，你可以让自己坐上火车，有一个有趣的命令行体验。
|
||||
|
||||
> 使用 sl 命令，你可以让自己驾驶火车，带来一个有趣的命令行体验。
|
||||
|
||||
|
||||
|
||||
现在是 12 月，每个 Linux 终端用户都值得这一年的奖励。因此, 我们将为你带来一个 Linux 命令行玩具的出现日历。什么是命令行玩具？它可能是一个游戏、一个小的无意义的打发时间的东西，或者为你在终端带来快乐的东西。
|
||||
现在是 12 月，每个 Linux 终端用户都值得这一年的奖励。因此，我们将为你带来一个 Linux 命令行玩具的日历。什么是命令行玩具？它可能是一个游戏、一个小的无意义的打发时间的东西，或者为你在终端带来快乐的东西。
|
||||
|
||||
今天的 Linux 命令行玩具是来自 Opensource.com 社区版主 [Ben Cotton][1] 的建议。Ben 建议 `sl`，它是蒸汽机车的简称。
|
||||
今天的 Linux 命令行玩具来自 Opensource.com 社区版主 [Ben Cotton][1] 的建议。Ben 建议 `sl`，它是<ruby>蒸汽机车<rt>steam locomotive</rt></ruby>的简称。
|
||||
|
||||
对于 Linux **ls** 命令来说，它也是一个常见的错误，而不是巧合。想要不再打错吗？尝试安装 **sl**。它可能已经在默认仓库中打包。对我而言，在 Fedora 中，这意味着安装起来很简单：
|
||||
而对于 Linux `ls` 命令来说，`sl` 也是一个常见的拼写错误，这并不是巧合（LCTT 译注：意即 `sl` 是专门用来设计提醒 `ls` 打错的）。想要不再打错吗？尝试安装 `sl`。它可能已经在默认仓库中打包。对我而言，在 Fedora 中，这意味着安装起来很简单：
|
||||
|
||||
```
|
||||
$ sudo dnf install sl -y
|
||||
```
|
||||
|
||||
现在，只需键入**sl** 即可测试。
|
||||
现在，只需键入 `sl` 即可测试。
|
||||
|
||||
|
||||
|
||||
你可能会像我一样注意到，**Ctrl+C** 不会让你的火车脱轨，所以你必须等待整列火车通过。这会让你知道打错了 **ls**！
|
||||
你可能会像我一样注意到，`Ctrl+C` 不会让你的火车脱轨，所以你必须等待整列火车通过。这会让你知道打错了 `ls`！
|
||||
|
||||
想查看 `sl` 源码？它已经在[在 GitHub 上][2]。
|
||||
|
||||
想查看 **sl** 源码？它已经在[在 GitHub 上][2]。
|
||||
`sl` 也是分享我个人关于开源许可证的见解的绝佳机会。虽然它的[许可证][3]“足够开源”能够打包到我的发行版，但技术上而言，它并不是 [OSI 批准][4]的许可证。在其版权行之后，许可证的内容很简单：
|
||||
|
||||
**sl** 也是分享关于开源许可的个人 PSA 的绝佳机会。虽然它的[许可证][3]“足够开源”以便为我的发行版打包，但技术上而言，它并不是 [OSI 批准][4]的许可证。在版权行之后，许可证的内容很简单:
|
||||
|
||||
```
|
||||
Everyone is permitted to do anything on this program including copying,
|
||||
modifying, and improving, unless you try to pretend that you wrote it.
|
||||
i.e., the above copyright notice has to appear in all copies.
|
||||
THE AUTHOR DISCLAIMS ANY RESPONSIBILITY WITH REGARD TO THIS SOFTWARE.
|
||||
```
|
||||
> 每个人都可以在这个程序上做任何事情，包括复制，修改和改进，除非你试图假装你写了它。
|
||||
>
|
||||
> 即，上述版权声明必须出现在所有副本中。
|
||||
>
|
||||
> 作者对本软件不承担任何责任。
|
||||
|
||||
遗憾的是，当你选择未经 OSI 批准的许可证时，你可能会意外地为你的用户带来额外的工作，因为他们必须要弄清楚你的许可证是否适用于他们的情况。他们的公司政策是否允许他们做贡献？甚至他们可以合法地使用该程序吗？许可证是否与他们希望与之集成的其他程序的许可证相匹配？
|
||||
|
||||
除非你是律师（也许，即使你是律师），否则在非标准许可证范围内选择可能会很棘手。因此，如果你仍在寻找新年的方案，为什么不把仅 OSI 批准的许可证作为你 2019 年新项目的选择呢。
|
||||
|
||||
这并不是对作者的不尊重。**sl** 仍然是一个很棒的小命令行玩具。
|
||||
这并不是对作者的不尊重。`sl` 仍然是一个很棒的小命令行玩具。
|
||||
|
||||
你有一个你认为我应该介绍的最喜欢的命令行玩具吗？这个系列的日历大部分已经完成，但我还剩下几个空余。请在下面的评论中告诉我，我会了解一下。如果有空间，我会尝试包含它。如果没有，但我得到了一些好的投稿，我会在最后做一些荣誉介绍。
|
||||
|
||||
@ -57,7 +57,7 @@ via: https://opensource.com/article/18/12/linux-toy-sl
|
||||
作者：[Jason Baker][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/) 荣誉推出
|
||||
|
||||
@ -67,4 +67,4 @@ via: https://opensource.com/article/18/12/linux-toy-sl
|
||||
[2]: https://github.com/mtoyoda/sl
|
||||
[3]: https://github.com/mtoyoda/sl/blob/master/LICENSE
|
||||
[4]: https://opensource.org/licenses
|
||||
[5]: https://opensource.com/article/18/12/linux-toy-boxes
|
||||
[5]: https://opensource.com/article/18/12/linux-toy-boxes
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -1,138 +0,0 @@
|
||||
[Translating by ChiZelin]
|
||||
3 best practices for continuous integration and deployment
|
||||
======
|
||||
Learn about automating, using a Git repository, and parameterizing Jenkins pipelines.
|
||||
|
||||
|
||||
The article covers three key topics: automating CI/CD configuration, using a Git repository for common CI/CD artifacts, and parameterizing Jenkins pipelines.
|
||||
|
||||
### Terminology
|
||||
|
||||
First things first; let's define a few terms. **CI/CD** is a practice that allows teams to quickly and automatically test, package, and deploy their applications. It is often achieved by leveraging a server called **[Jenkins][1]** , which serves as the CI/CD orchestrator. Jenkins listens to specific inputs (often a Git hook following a code check-in) and, when triggered, kicks off a pipeline.
|
||||
|
||||
A **pipeline** consists of code written by development and/or operations teams that instructs Jenkins which actions to take during the CI/CD process. This pipeline is often something like "build my code, then test my code, and if those tests pass, deploy my application to the next highest environment (usually a development, test, or production environment)." Organizations often have more complex pipelines, incorporating tools such as artifact repositories and code analyzers, but this provides a high-level example.
|
||||
|
||||
Now that we understand the key terminology, let's dive into some best practices.
|
||||
|
||||
### 1\. Automation is key
|
||||
|
||||
To run CI/CD on a PaaS, you need the proper infrastructure to be configured on the cluster. In this example, I will use [OpenShift][2].
|
||||
|
||||
"Hello, World" implementations of this are quite simple to achieve. Simply run **oc new-app jenkins- <persistent/ephemeral>** and voilà, you have a running Jenkins server ready to go. Uses in the enterprise, however, are much more complex. In addition to the Jenkins server, admins will often need to deploy a code analysis tool such as SonarQube and an artifact repository such as Nexus. They will then have to create pipelines to perform CI/CD and Jenkins slaves to reduce the load on the master. Most of these entities are backed by OpenShift resources that need to be created to deploy the desired CI/CD infrastructure.
|
||||
|
||||
Eventually, the manual steps required to deploy your CI/CD components may need to be replicated, and you might not be the person to perform those steps. To ensure the outcome is produced quickly, error-free, and exactly as it was before, an automation method should be incorporated in the way your infrastructure is created. This can be an Ansible playbook, a Bash script, or any other way you would like to automate the deployment of CI/CD infrastructure. I have used [Ansible][3] and the [OpenShift-Applier][4] role to automate my implementations. You may find these tools valuable, or you may find something else that works better for you and your organization. Either way, you'll find that automation significantly reduces the workload required to recreate CI/CD components.
|
||||
|
||||
#### Configuring the Jenkins master
|
||||
|
||||
Outside of general "automation," I'd like to single out the Jenkins master and talk about a few ways admins can take advantage of OpenShift to automate Jenkins configuration. The Jenkins image from the [Red Hat Container Catalog][5] comes packaged with the [OpenShift-Sync plugin][6] installed. In the [video][7], we discuss how this plugin can be used to create Jenkins pipelines and slaves.
|
||||
|
||||
To create a Jenkins pipeline, create an OpenShift BuildConfig similar to this:
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: BuildConfig
|
||||
...
|
||||
spec:
|
||||
source:
|
||||
git:
|
||||
ref: master
|
||||
uri: <repository-uri>
|
||||
...
|
||||
strategy:
|
||||
jenkinsPipelineStrategy:
|
||||
jenkinsfilePath: Jenkinsfile
|
||||
type: JenkinsPipeline
|
||||
```
|
||||
|
||||
The OpenShift-Sync plugin will notice that a BuildConfig with the strategy **jenkinsPipelineStrategy** has been created and will convert it into a Jenkins pipeline, pulling from the Jenkinsfile specified by the Git source. An inline Jenkinsfile can also be used instead of pulling from one from a Git repository. See the [documentation][8] for more information.
|
||||
|
||||
To create a Jenkins slave, create an OpenShift ImageStream that starts with the following definition:
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: ImageStream
|
||||
metadata:
|
||||
annotations:
|
||||
slave-label: jenkins-slave
|
||||
labels:
|
||||
role: jenkins-slave
|
||||
…
|
||||
```
|
||||
|
||||
Notice the metadata defined in this ImageStream. The OpenShift-Sync plugin will convert any ImageStream with the label **role: jenkins-slave** into a Jenkins slave. The Jenkins slave will be named after the value from the **slave-label** annotation.
|
||||
|
||||
ImageStreams work just fine for simple Jenkins slave configurations, but some teams will find it necessary to configure nitty-gritty details such as resource limits, readiness and liveness probes, and instance caps. This is where ConfigMaps come into play:
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
labels:
|
||||
role: jenkins-slave
|
||||
...
|
||||
data:
|
||||
template1: |-
|
||||
<Kubernetes pod template>
|
||||
```
|
||||
|
||||
Notice that the **role: jenkins-slave** label is still required to convert the ConfigMap into a Jenkins slave. The **Kubernetes pod template** consists of a lengthy bit of XML that will configure every detail to your organization's liking. To view this XML, as well as more information on converting ImageStreams and ConfigMaps into Jenkins slaves, see the [documentation][9].
|
||||
|
||||
Notice with the three examples shown above that none of the operations required an administrator to make manual changes to the Jenkins console. By using OpenShift resources, Jenkins can be configured in a way that is easily automated.
|
||||
|
||||
### 2\. Sharing is caring
|
||||
|
||||
The second best practice is maintaining a Git repository of common CI/CD artifacts. The main idea is to prevent teams from reinventing the wheel. Imagine your team needs to perform a blue/green deployment to an OpenShift environment as part of the pipeline's CD phase. The members of your team responsible for writing the pipeline may not be OpenShift experts, nor may they have the bandwidth to write this functionality from scratch. Luckily, somebody has already written a function that incorporates that functionality in a common CI/CD repository, so your team can use that function instead of spending time writing one.
|
||||
|
||||
To take this a step further, your organization may decide to maintain entire pipelines. You may find that teams are writing pipelines with similar functionality. It would be more efficient for those teams to use a parameterized pipeline from a common repository as opposed to writing their own from scratch.
|
||||
|
||||
### 3\. Less is more
|
||||
|
||||
As I hinted in the previous section, the third and final best practice is to parameterize your CI/CD pipelines. Parameterization will prevent an over-abundance of pipelines, making your CI/CD system easier to maintain. Imagine I have multiple regions where I can deploy my application. Without parameterization, I would need a separate pipeline for each region.
|
||||
|
||||
To parameterize a pipeline written as an OpenShift build config, add the **env** stanza to the configuration:
|
||||
|
||||
```
|
||||
...
|
||||
spec:
|
||||
...
|
||||
strategy:
|
||||
jenkinsPipelineStrategy:
|
||||
env:
|
||||
- name: REGION
|
||||
value: US-West
|
||||
jenkinsfilePath: Jenkinsfile
|
||||
type: JenkinsPipeline
|
||||
```
|
||||
|
||||
With this configuration, I can pass the **REGION** parameter the pipeline to deploy my application to the specified region.
|
||||
|
||||
The [video][7] provides a more substantial case where parameterization is a must. Some organizations decide to split up their CI/CD pipelines into separate CI and CD pipelines, usually, because there is some sort of approval process that happens before deployment. Imagine I have four images and three different environments to deploy to. Without parameterization, I would need 12 CD pipelines to allow all deployment possibilities. This can get out of hand very quickly. To make maintenance of the CD pipeline easier, organizations would find it better to parameterize the image and environment to allow one pipeline to perform the work of many.
|
||||
|
||||
### Summary
|
||||
|
||||
CI/CD at the enterprise level tends to become more complex than many organizations anticipate. Luckily, with Jenkins, there are many ways to seamlessly provide automation of your setup. Maintaining a Git repository of common CI/CD artifacts will also ease the effort, as teams can pull from maintained dependencies instead of writing their own from scratch. Finally, parameterization of your CI/CD pipelines will reduce the number of pipelines that will have to be maintained.
|
||||
|
||||
If you've found other practices you can't do without, please share them in the comments.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/11/best-practices-cicd
|
||||
|
||||
作者：[Austin Dewey][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://opensource.com/users/adewey
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://jenkins.io/
|
||||
[2]: https://www.openshift.com/
|
||||
[3]: https://docs.ansible.com/
|
||||
[4]: https://github.com/redhat-cop/openshift-applier
|
||||
[5]: https://access.redhat.com/containers/?tab=overview#/registry.access.redhat.com/openshift3/jenkins-2-rhel7
|
||||
[6]: https://github.com/openshift/jenkins-sync-plugin
|
||||
[7]: https://www.youtube.com/watch?v=zlL7AFWqzfw
|
||||
[8]: https://docs.openshift.com/container-platform/3.11/dev_guide/dev_tutorials/openshift_pipeline.html#the-pipeline-build-config
|
||||
[9]: https://docs.openshift.com/container-platform/3.11/using_images/other_images/jenkins.html#configuring-the-jenkins-kubernetes-plug-in
|
||||
@ -1,111 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to Install Putty on Ubuntu and Other Linux Distributions)
|
||||
[#]: via: (https://itsfoss.com/putty-linux/)
|
||||
[#]: author: (Abhishek Prakash https://itsfoss.com/author/abhishek/)
|
||||
|
||||
How to Install Putty on Ubuntu and Other Linux Distributions
|
||||
======
|
||||
|
||||
If I am not wrong, [Putty][1] is perhaps the most popular SSH client for Windows.
|
||||
|
||||
In IT companies, the development environment is usually on a remote Linux system while the developers use Windows as their local system. Putty is used for connecting to the remote Linux system from the Windows machine.
|
||||
|
||||
Putty is not limited to Windows only. You can also use this open source software on Linux and macOS.
|
||||
|
||||
But wait! Why would you use a separate SSH client on Linux when you already have the ‘real’ Linux terminal with you? There are several reasons why you would want to use Putty on Linux.
|
||||
|
||||
* You have used Putty for so long on Windows that you are more comfortable with it.
|
||||
* You find it difficult to manually edit SSH config file to save the various SSH sessions. You prefer Putty’s graphical way of storing SSH connection.
|
||||
* You want to debug by connecting to raw sockets and serial ports.
|
||||
|
||||
|
||||
|
||||
Whatever may be the reason, if you want to use Putty on Ubuntu or any other Linux, you can certainly do so. Let me show you how to do that.
|
||||
|
||||
### Installing Putty on Ubuntu Linux
|
||||
|
||||
![Installing Putty on Linux][2]
|
||||
|
||||
The good news for the Ubuntu users is that Putty is available in the universe repository of Ubuntu.
|
||||
|
||||
To install Putty on Ubuntu, you should first make sure that the universe repository is enabled.
|
||||
|
||||
```
|
||||
sudo add-apt-repository universe
|
||||
```
|
||||
|
||||
Once you have the universe repository enabled, you should update Ubuntu with this command:
|
||||
|
||||
```
|
||||
sudo apt update
|
||||
```
|
||||
|
||||
After this, you can install Putty with this command:
|
||||
|
||||
```
|
||||
sudo apt install putty
|
||||
```
|
||||
|
||||
Once installed, you can start Putty by finding it in the menu.
|
||||
|
||||
As you can see in the screenshot below, the Linux version of Putty looks the same as the Windows version. That’s a relief because you won’t have to fiddle around trying to find your way through a new and changed settings.
|
||||
|
||||
![Putty in Linux][3]
|
||||
|
||||
When you enter the remote system’s [hostname][4] or IP address and connect to it, Putty will utilize the already saved SSH keys in your home directory.
|
||||
|
||||
![Using Putty in Ubuntu Linux][5]
|
||||
|
||||
### Installing Putty on other Linux distributions
|
||||
|
||||
[Putty is available for Debian][6] so you just need to use apt-get or aptitude for installing it.
|
||||
|
||||
```
|
||||
sudo apt-get install putty
|
||||
```
|
||||
|
||||
Putty is also available for Fedora/Red Hat and can be installed using the default package manager.
|
||||
|
||||
```
|
||||
sudo dnf install putty
|
||||
```
|
||||
|
||||
You can also easily install Putty in Arch Linux based distributions.
|
||||
|
||||
```
|
||||
sudo pacman -S putty
|
||||
```
|
||||
|
||||
Remember that Putty is an open source software. You can also install it via source code if you really want to. You can get the source code of Putty from the link below.
|
||||
|
||||
[Download Putty Source Code][8]
|
||||
|
||||
I would always prefer the native Linux terminal over an SSH client like Putty. I feel more at home with the GNOME terminal or [Terminator][7]. However, it’s up to an individual’s choice to use the default terminal or Putty in Linux
|
||||
|
||||
What do you use for managing multiple SSH connections on Linux?
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/putty-linux/
|
||||
|
||||
作者：[Abhishek Prakash][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://itsfoss.com/author/abhishek/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.putty.org/
|
||||
[2]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2018/12/Putty-linux.png?resize=800%2C450&ssl=1
|
||||
[3]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2018/12/putty-interface-ubuntu.jpeg?resize=800%2C503&ssl=1
|
||||
[4]: https://itsfoss.com/change-hostname-ubuntu/
|
||||
[5]: https://i2.wp.com/itsfoss.com/wp-content/uploads/2018/12/putty-interface-ubuntu-1.jpeg?resize=800%2C430&ssl=1
|
||||
[6]: https://packages.debian.org/jessie/putty
|
||||
[7]: https://launchpad.net/terminator
|
||||
[8]: https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
|
||||
@ -1,133 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (HankChow)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Aliases: DIY Shell Commands)
|
||||
[#]: via: (https://www.linux.com/blog/learn/2018/12/aliases-diy-shell-commands)
|
||||
[#]: author: (Paul Brown https://www.linux.com/users/bro66)
|
||||
|
||||
Aliases: DIY Shell Commands
|
||||
======
|
||||
|
||||
|
||||
|
||||
Aliases, in the context of the Linux shell, are **commands you build yourself** by packing them with combinations of other instructions that are too long or too hard to remember.
|
||||
|
||||
You create an alias by using the word `alias`, then the name of the command you want to create, an equal sign (`=`), and then the Bash command(s) you want your alias to run. For example, `ls` in its base form does not colorize its output, making it difficult to distinguish between directories, files, and links. You can build a new command that shows colors by making an alias like this:
|
||||
|
||||
```
|
||||
alias lc='ls --color=auto'
|
||||
```
|
||||
|
||||
where `lc` is the name you have picked for your new command. When creating aliases, be sure to check that the name you picked isn't already in use, or you may override an existing command. In this case, `lc` stands for "list (with) color". Notice there is no space in front of or behind the `=`. Finally, you have the regular Bash command(s) you want to run when `lc` is executed. In this case, the `ls` command with the `--color` option.
|
||||
|
||||
After defining your alias, every time you type `lc`, the contents of the current directory will be shown in color.
|
||||
|
||||
But, you may think, "my `ls` command already lists files in different colors!" That is because most Linux distros come with some aliases already set up for you.
|
||||
|
||||
### Aliases you (probably) already have
|
||||
|
||||
Indeed, you can use the `alias` instruction without any options to see what aliases you already have. These will vary by distro, but some typical preset aliases are:
|
||||
|
||||
* `alias ls='ls --color=auto'`: You already saw this one above. The `auto` modifier of the `--color` option tells `ls` to use color when standard output is connected to a terminal. That is, the output of `ls` is going to show up in a terminal window or a text screen, instead of, say, being piped to a file. Other alternatives for `--color` are `always` and `never`.
|
||||
* `alias cp='cp -i'`: The `-i` option stands for _interactive_. Sometimes, when you use `cp` you may inadvertently overwrite an existing file. By using the `-i`, `cp` will ask you before clobbering anything.
|
||||
* `alias free='free -m'`: Using `-m` with `free`you can see how much free memory you have and how much your applications are using in megabytes instead of the default bytes. This makes the output of `free` easier to read for a human.
|
||||
|
||||
|
||||
|
||||
There may be more (or less, or even none), but regardless of what your distribution comes with, you can always use the base form (vs. the aliased form) of a command with the `\` modifier. For example:
|
||||
|
||||
```
|
||||
\free
|
||||
```
|
||||
|
||||
will execute `free` without the `-m` option, and
|
||||
|
||||
```
|
||||
\ls
|
||||
```
|
||||
|
||||
will execute `ls` without the `--color=auto` option.
|
||||
|
||||
If you want to get rid or modify the preset aliases forever, note that they live in the global _.bashrc_ file which hangs out in [our old haunt, the _/etc/skel_ directory][1].
|
||||
|
||||
### Aliases for muscle memory
|
||||
|
||||
Distro designers try their best to predict which aliases are going to be useful for you. But every user is different and comes from a different background. If you are new to GNU+Linux, it may be because you are coming from another system, and the basic commands vary from shell to shell. If you come from a Windows/MS-DOS background, you may want to define an alias like
|
||||
|
||||
```
|
||||
alias dir='ls'
|
||||
```
|
||||
|
||||
to list files or directories.
|
||||
|
||||
Likewise,
|
||||
|
||||
```
|
||||
alias copy='cp'
|
||||
alias move='mv'
|
||||
```
|
||||
|
||||
may also come in handy, at least until you get used to Linux's new lexicon.
|
||||
|
||||
The other problem occurs when mistakes become ingrained in your muscle memory, so you always mistype some words the same way. I, for instance, have great difficulty typing _admnis-_... _adminsi-_... _A-D-M-I-N-I-S-T-R-A-T-I-ON_ ( _phew!_ ) at speed. That is why some users create aliases like
|
||||
|
||||
```
|
||||
alias sl='ls'
|
||||
```
|
||||
|
||||
and
|
||||
|
||||
```
|
||||
alias gerp='echo "You did it *again*!"; grep'
|
||||
```
|
||||
|
||||
Although we haven't formally introduced `grep` yet, in its most basic form, it looks for a string of characters in a file or a set of files. It's one of those commands that you will tend to use A LOT once you get to grips with it, as those ingrained mistyping habits that force you to type the instruction twice every time get annoying really quickly.
|
||||
|
||||
Another thing to note in the `gerp` example is that it is not a single instruction, but two. The first one (`echo "You did it *again*!"`) prints out a message reminding you that you misspelled the grep command, then there is a semicolon (`;`) that separates one instruction from the other. Finally, you've got the second command (`grep`) that does the actual grepping.
|
||||
|
||||
Using `gerp` on my system to search for the lines containing the word " _alias_ " in _/etc/skel/.bashrc_ , the output looks like this:
|
||||
|
||||
```
|
||||
$ gerp -R alias /etc/skel/.bashrc
|
||||
You did it *again*!
|
||||
alias ls='ls --color=auto'
|
||||
alias grep='grep --colour=auto'
|
||||
alias egrep='egrep --colour=auto'
|
||||
alias fgrep='fgrep --colour=auto'
|
||||
alias cp="cp -i"
|
||||
alias df='df -h'
|
||||
alias free='free -m'
|
||||
alias np='nano -w PKGBUILD'
|
||||
alias more=less
|
||||
shopt -s expand_aliases
|
||||
```
|
||||
|
||||
Running commands sequentially as part of an alias, or, even better, chaining commands so that one command can use the results coughed up by another, is getting us perilously close to Bash scripting. This has been in the making of this series for quite some time, and we'll start covering it in the very next article.
|
||||
|
||||
For the time being, if you want to get rid of an alias you temporarily set up in a running terminal, use the `unalias` command:
|
||||
|
||||
```
|
||||
unalias gerp
|
||||
```
|
||||
|
||||
If you want to make your aliases permanent, you can drop them into the _.bashrc_ file you have in your home directory. This is the same thing we did with custom environment variables in [last week's article][2].
|
||||
|
||||
See you next time!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/blog/learn/2018/12/aliases-diy-shell-commands
|
||||
|
||||
作者：[Paul Brown][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.linux.com/users/bro66
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.linux.com/learn/intro-to-linux/2018/7/users-groups-and-other-linux-beasts
|
||||
[2]: https://www.linux.com/blog/learn/2018/12/bash-variables-environmental-and-otherwise
|
||||
@ -0,0 +1,137 @@
|
||||
持续集成与部署的3个最佳实践
|
||||
======
|
||||
了解自动化，使用 Git 存储库以及参数化 Jenkins 管道。
|
||||
|
||||
|
||||
本文涵盖了三个关键主题：自动化 CI/CD 配置、使用 Git 存储库处理常见的 CI/CD 工件、参数化 Jenkins 管道。
|
||||
|
||||
### 术语
|
||||
|
||||
首先，我们定义一些术语。**CI/CD** 是允许团队快速自动化测试、打包、部署其应用程序的实践。它通常通过利用名为 **[Jenkins][1]** 的服务器来实现，该服务器充当 CI/CD 协调器。Jenkins 侦听特定输入（通常是代码签入后的 Git hook），并在触发时启动管道。
|
||||
|
||||
**pipeline** 由开发和/或运营团队编写的代码组成，这些代码指导 Jenkins 在 CI/CD 过程中采取哪些操作。这个流水线通常类似于“构建我的代码，然后测试我的代码，如果这些测试通过，则把我的应用程序部署到下一个最高环境（通常是开发、测试或生产环境）”。组织通常具有更复杂的流水线，并入了诸如工件存储库和代码分析器之类的工具，但是这提供了一个高级示例。
|
||||
|
||||
现在我们了解了关键术语，让我们深入研究一些最佳实践。
|
||||
|
||||
### 1\. 自动化是关键
|
||||
|
||||
要在 PaaS 上运行 CI/CD，需要在集群上配置适当的基础设施。在这个例子中，我将使用 [OpenShift][2]。
|
||||
|
||||
"Hello, World" 的实现很容易实现。简单地运行 **oc new-app jenkins- <persistent/ephemeral>** 和 voilà, 你已经准备好运行 Jenkins 服务器了。然而，在企业中的使用要复杂得多。除了 Jenkins 服务器之外，管理员通常还需要部署代码分析工具（如 SonarQube）和构件库（如 Nexus）。然后，它们必须创建管道来执行 CI/CD 和 Jenkins 从服务器，以减少主服务器的负载。这些实体中的大多数都由 OpenShift 资源支持，需要创建这些资源来部署所需的 CI/CD 基础设施。
|
||||
|
||||
最后，部署 CI/CD 组件所需要的手动步骤可能是需要被重复的，并且你可能不想成为执行那些重复步骤的人。为了确保结果能够像以前一样快速、无错误和准确地产生，应该在创建基础设施的方式中结合自动化方法。这可以是一个 Ansible 剧本、一个 Bash 脚本，或者任何您希望自动化 CI/CD 基础设施部署的其他方式。我已经使用 [Ansible][3] 和 [OpenShift-Applier][4] 角色来自动化我的实现。您可能会发现这些工具很有价值，或者您可能会发现其他一些对您和组织更有效的工具。无论哪种方式，您都将发现自动化显著地减少了重新创建 CI/CD 组件所需的工作量。
|
||||
|
||||
#### 配置Jenkins主服务器
|
||||
|
||||
除了一般的“自动化”之外，我想单独介绍一下 Jenkins 主服务器，并讨论管理员如何利用 OpenShift 来自动化配置 Jenkins。来自 [Red Hat Container Catalog][5] 的 Jenkins 映像已经安装了 [OpenShift-Sync plugin][6]。在 [视频][7] 中，我们将讨论如何使用这个插件来创建 Jenkins 管道和从设备。
|
||||
|
||||
要创建 Jenkins 流水线，请创建一个类似于下面的 OpenShift BuildConfig：
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: BuildConfig
|
||||
...
|
||||
spec:
|
||||
source:
|
||||
git:
|
||||
ref: master
|
||||
uri: <repository-uri>
|
||||
...
|
||||
strategy:
|
||||
jenkinsPipelineStrategy:
|
||||
jenkinsfilePath: Jenkinsfile
|
||||
type: JenkinsPipeline
|
||||
```
|
||||
|
||||
OpenShift-Sync 插件将注意到已经创建了带有 **jenkinsPipelineStrategy** 策略的 BuildConfig，并将其转换为 Jenkins 管道，从 Git 源指定的 Jenkins 文件中提取。也可以使用内联 Jenkinsfile，而不是从 Git 存储库中提取。有关更多信息，请参阅[文档][8]。
|
||||
|
||||
要创建 Jenkins 从站，请创建一个 OpenShift ImageStream，它从以下定义开始：
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: ImageStream
|
||||
metadata:
|
||||
annotations:
|
||||
slave-label: jenkins-slave
|
||||
labels:
|
||||
role: jenkins-slave
|
||||
…
|
||||
```
|
||||
|
||||
注意在这个 ImageStream 中定义的元数据。OpenShift-Sync 插件将把带有标签 **role: jenkins-slave** 的任何ImageStream 转换为 Jenkins 从站。Jenkins 从站将以 **slave-label** 注释中的值命名。
|
||||
|
||||
ImageStreams 对于简单的 Jenkins 从属配置工作得很好，但是一些团队会发现有必要配置一些细节详情，比如资源限制、准备就绪和活动性探测，以及实例帽。这就是 ConfigMap 发挥作用的地方：
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
labels:
|
||||
role: jenkins-slave
|
||||
...
|
||||
data:
|
||||
template1: |-
|
||||
<Kubernetes pod template>
|
||||
```
|
||||
|
||||
注意，仍然需要角色：jenkins-slave 标签来将 ConfigMap 转换为 Jenkins slave。Kubernetes pod 模板由一长段 XML 组成，它将根据组织的喜好配置每个细节。要查看此 XML，以及有关将 ImageStreams 和 ConfigMaps 转换为 Jenkins 从属的更多信息，请参阅[文档][9]。
|
||||
|
||||
请注意上面所示的三个示例，其中没有一个操作需要管理员对 Jenkins 控制台进行手动更改。通过使用 OpenShift 资源，可以简单的自动化方式配置 Jenkins。
|
||||
|
||||
### 2\. 分享就是关心
|
||||
|
||||
第二个最佳实践是维护一个公共 CI/CD 工件的 Git 存储库。主要思想是防止团队重新发明轮子。假设您的团队需要执行到 OpenShift 环境的蓝色/绿色部署，作为管道 CD 阶段的一部分。负责编写流水线的团队成员可能不是 OpenShift 专家，也不可能具有从头开始编写此功能的能力。幸运的是，有人已经编写了一个将此功能合并到一个公共 CI/CD 存储库中的函数，因此您的团队可以使用该函数而不是花时间编写一个函数。
|
||||
|
||||
为了更进一步，您的组织可能决定维护整个管道。您可能会发现团队正在编写具有相似功能的流水线。对于那些团队来说，使用来自公共存储库的参数化管道要比从头开始编写自己的管道更有效。
|
||||
|
||||
### 3\. 少即是多
|
||||
|
||||
正如我在前一节中提到的，第三个也是最后一个最佳实践是参数化您的 CI/CD 管道。参数化将防止过多的管道，使您的 CI/CD 系统更容易维护。假设我有多个区域可以部署应用程序。如果没有参数化，我需要为每个区域设置单独的管道。
|
||||
|
||||
要参数化作为 OpenShift 构建配置编写的管道，请将 **env** 节添加到配置：
|
||||
|
||||
```
|
||||
...
|
||||
spec:
|
||||
...
|
||||
strategy:
|
||||
jenkinsPipelineStrategy:
|
||||
env:
|
||||
- name: REGION
|
||||
value: US-West
|
||||
jenkinsfilePath: Jenkinsfile
|
||||
type: JenkinsPipeline
|
||||
```
|
||||
|
||||
使用此配置，我可以传递 **REGION** 参数管道以将我的应用程序部署到指定区域。
|
||||
|
||||
这有一个[视频][7]提供了一个更实质性的情况，其中参数化是必须的。一些组织决定把他们的 CI/CD 管道分割成单独的 CI 和 CD 管道，通常是因为在部署之前有一些审批过程。假设我有四个映像和三个不同的环境要部署。如果没有参数化，我需要12个 CD 管道来允许所有部署可能性。这会很快失去控制。为了使 CD 流水线的维护更容易，组织会发现将映像和环境参数化以便允许一个流水线执行多个流水线的工作会更好。
|
||||
|
||||
### 总结
|
||||
|
||||
企业级的 CI/CD 往往比许多组织预期的更加复杂。幸运的是，对于 Jenkins，有很多方法可以无缝地提供设置的自动化。维护一个公共 CI/CD 工件的 Git 存储库也会减轻工作量，因为团队可以从维护的依赖项中提取而不是从头开始编写自己的依赖项。最后，CI/CD 管道的参数化将减少必须维护的管道的数量。
|
||||
|
||||
如果您找到了其他不可或缺的做法，请在评论中分享。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/11/best-practices-cicd
|
||||
|
||||
作者：[Austin Dewey][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[ChiZelin](https://github.com/ChiZelin)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/adewey
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://jenkins.io/
|
||||
[2]: https://www.openshift.com/
|
||||
[3]: https://docs.ansible.com/
|
||||
[4]: https://github.com/redhat-cop/openshift-applier
|
||||
[5]: https://access.redhat.com/containers/?tab=overview#/registry.access.redhat.com/openshift3/jenkins-2-rhel7
|
||||
[6]: https://github.com/openshift/jenkins-sync-plugin
|
||||
[7]: https://www.youtube.com/watch?v=zlL7AFWqzfw
|
||||
[8]: https://docs.openshift.com/container-platform/3.11/dev_guide/dev_tutorials/openshift_pipeline.html#the-pipeline-build-config
|
||||
[9]: https://docs.openshift.com/container-platform/3.11/using_images/other_images/jenkins.html#configuring-the-jenkins-kubernetes-plug-in
|
||||
@ -0,0 +1,111 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to Install Putty on Ubuntu and Other Linux Distributions)
|
||||
[#]: via: (https://itsfoss.com/putty-linux/)
|
||||
[#]: author: (Abhishek Prakash https://itsfoss.com/author/abhishek/)
|
||||
|
||||
如何在 Ubuntu 和其他 Linux 发行版上安装 Putty
|
||||
======
|
||||
|
||||
如果我没错，[Putty][1] 可能是 Windows 最受欢迎的 SSH 客户端。
|
||||
|
||||
I在 IT 公司中，开发环境通常在远程 Linux 系统上，而开发人员则使用 Windows 作为本地系统。Putty 用于从 Windows 机器连接到远程 Linux 系统。
|
||||
|
||||
Putty 不仅限于 Windows。你也可以在 Linux 和 macOS 上使用此开源软件。
|
||||
|
||||
但是等等！当你已经拥有“真正的” Linux 终端时，为什么要在 Linux 上使用单独的 SSH 客户端？这有几个想在 Linux 上使用 Putty 的原因。
|
||||
|
||||
* 你在 Windows 上使用 Putty 已经很久了，你觉得它更舒服。
|
||||
* 你发现很难手动编辑 SSH 配置文件以保存各种 SSH 会话。你更喜欢 Putty 图形化保存 SSH 连接的方式。
|
||||
* 你想通过连接到原始套接字和串口进行调试。
|
||||
|
||||
|
||||
|
||||
无论是什么原因，如果你想在 Ubuntu 或任何其他 Linux 上使用 Putty，你当然可以这样做。让我告诉你如何做到。
|
||||
|
||||
### 在 Ubuntu Linux 上安装 Putty
|
||||
|
||||
![Installing Putty on Linux][2]
|
||||
|
||||
对于 Ubuntu 用户来说，好消息是 Putty 可以在 Ubuntu 的 universe 仓库中找到。
|
||||
|
||||
要在 Ubuntu上安装 Putty，首先应确保已启用 universe 仓库。
|
||||
|
||||
```
|
||||
sudo add-apt-repository universe
|
||||
```
|
||||
|
||||
启用 universe 存储库后，应使用以下命令更新 Ubuntu：
|
||||
|
||||
```
|
||||
sudo apt update
|
||||
```
|
||||
|
||||
之后，你可以使用以下命令安装 Putty：
|
||||
|
||||
```
|
||||
sudo apt install putty
|
||||
```
|
||||
|
||||
安装后，你可以在菜单中找到它来启动 Putty。
|
||||
|
||||
正如你在下面的截图中看到的，Putty 的 Linux 版本看起来与 Windows 版本相同。这让你松了一口气, 因为你不必再尝试新的设置。
|
||||
|
||||
![Putty in Linux][3]
|
||||
|
||||
当你输入远程系统的[主机名][4]或 IP 地址并连接到它时，Putty 将使用你主目录中已保存的 SSH 密钥。
|
||||
|
||||
![Using Putty in Ubuntu Linux][5]
|
||||
|
||||
### 在其他 Linux 发行版上安装 Putty
|
||||
|
||||
[Putty 可用于 Debian][6]，所以你只需要使用 apt-get 或 aptitude 来安装它。
|
||||
|
||||
```
|
||||
sudo apt-get install putty
|
||||
```
|
||||
|
||||
Putty 也适用于 Fedora/Red Hat，并可以使用默认的包管理器进行安装。
|
||||
|
||||
```
|
||||
sudo dnf install putty
|
||||
```
|
||||
|
||||
你还可以在基于 Arch Linux 的发行版中轻松安装 Putty。
|
||||
|
||||
```
|
||||
sudo pacman -S putty
|
||||
```
|
||||
|
||||
请记住，Putty 是一款开源软件。如果你真的想要，你也可以通过源代码安装它。你可以从下面的链接获取 Putty 的源代码。
|
||||
|
||||
[下载 Putty 源代码][8]
|
||||
|
||||
我一直喜欢原生 Linux 终端而不是像 Putty 这样的 SSH 客户端。我觉得 GNOME 终端或 [Terminator][7] 更有家的感觉。但是，在 Linux 中使用默认终端或 Putty 是个人选择。
|
||||
|
||||
你在 Linux 上管理多个 SSH 连接时使用了什么？
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/putty-linux/
|
||||
|
||||
作者：[Abhishek Prakash][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://itsfoss.com/author/abhishek/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.putty.org/
|
||||
[2]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2018/12/Putty-linux.png?resize=800%2C450&ssl=1
|
||||
[3]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2018/12/putty-interface-ubuntu.jpeg?resize=800%2C503&ssl=1
|
||||
[4]: https://itsfoss.com/change-hostname-ubuntu/
|
||||
[5]: https://i2.wp.com/itsfoss.com/wp-content/uploads/2018/12/putty-interface-ubuntu-1.jpeg?resize=800%2C430&ssl=1
|
||||
[6]: https://packages.debian.org/jessie/putty
|
||||
[7]: https://launchpad.net/terminator
|
||||
[8]: https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
|
||||
123
translated/tech/20181212 Aliases- DIY Shell Commands.md
Normal file
123
translated/tech/20181212 Aliases- DIY Shell Commands.md
Normal file
@ -0,0 +1,123 @@
|
||||
命令别名：定义自己的命令
|
||||
======
|
||||
|
||||
|
||||
|
||||
<ruby>命令别名<rt>Alias</rt></ruby>在 Linux shell 中指的是将一些太长或者太难记的多个命令组合起来，成为一个由用户自定义构建的命令。
|
||||
|
||||
可以通过 `alias` 命令来创建命令别名。在 `alias` 后面跟上想要创建的别名名称、一个等号（`=`），以及希望使用这个别名来执行的命令，这样一个命令别名就创建好了。举个例子，`ls` 命令在默认情况下是不会对输出的内容进行着色的，这样就不能让用户一眼分辨出目录、文件和连接了。对此，可以创建这样一个命令别名，在输出目录内容的时候为输出内容着色：
|
||||
|
||||
```
|
||||
alias lc='ls --color=auto'
|
||||
```
|
||||
|
||||
其中 `lc` 是自定义的命令别名，代表“list with color”的意思。在创建命令别名的时候，需要先确认使用的别名是不是已经有对应的命令了，如果有的话，原本的命令就会被覆盖掉了。注意，定义命令别名的时候，`=` 两端是没有空格的。当运行 `lc` 的时候，就相当于执行了 `ls --color` 命令。
|
||||
|
||||
此后，执行 `lc` 列出目录内容的时候，就会输出带有着色的内容了。
|
||||
|
||||
你可能会发现你在执行 `ls` 的时候，本来就是输出带有着色的内容。那是因为大部分 Linux 发行版都已经将 `ls` 设定为带有着色的命令别名了。
|
||||
|
||||
### 可以直接使用的命令别名
|
||||
|
||||
实际上，执行不带任何内容的 `alias` 命令就可以看到当前已经设定的所有命令别名。对于不同的发行版，包含的命令别名不尽相同，但普遍都会有以下这些命令别名：
|
||||
|
||||
* `alias ls='ls --color=auto'`：这个命令别名在前面已经提到过了。`--color=auto` 参数会让 `ls` 命令在通过标准输出在终端中显示内容时进行着色，而其它情况（例如通过管道输出到文件）下则不进行着色。`--color` 这个参数还可以设置为 `always` 或`never`。
|
||||
* `alias cp='cp -i'`：`-i` 参数代表“<ruby>交互<rt>interactive</rt></ruby>”。在使用 `cp` 命令复制文件的时候，可能会无意中覆盖现有的文件，在使用了 `-i` 参数之后，`cp` 命令会在一些关键操作前向用户发出询问。
|
||||
* `alias free='free -m'`：在 `free` 命令后面加上 `-m` 参数，就可以将输出的内存信息以 MiB 这个更方面阅读和计算的单位输出，而不是默认的 Byte 单位。
|
||||
|
||||
|
||||
|
||||
你使用的发行版自带的命令别名可能多多少少和上面有些差别。但你都可以在命令前面加上 `\` 修饰符来使用命令的最基本形式。例如：
|
||||
|
||||
```
|
||||
\free
|
||||
```
|
||||
|
||||
就是直接执行 `free`，而不是 `free -m`。还有：
|
||||
|
||||
```
|
||||
\ls
|
||||
```
|
||||
|
||||
执行的就是不带有`--color=auto` 参数的 `ls`。
|
||||
|
||||
如果想要持久地保存命令别名，可以在 `.bashrc` 文件中进行修改。
|
||||
|
||||
### 使用命令别名纠正错误
|
||||
|
||||
各种发行版的设计者都会尽量设置用户可能需要用到的命令别名。但是不同的用户的习惯各不相同，一些用户可能刚从其它操作系统迁移到 Linux，而不同操作系统的基本命令又因 shell 而异。因此，对于刚从 Windows/MS-DOS 系统迁移到 Linux 系统的用户，不妨使用
|
||||
|
||||
```
|
||||
alias dir='ls'
|
||||
```
|
||||
|
||||
这个命令别名来列出目录内容。
|
||||
|
||||
类似地，
|
||||
|
||||
```
|
||||
alias copy='cp'
|
||||
alias move='mv'
|
||||
```
|
||||
|
||||
也可以在尚未完全熟悉 Linux 的时候用得顺手。
|
||||
|
||||
还有一种情况，就是在经常出现输入错误的场合中做出容错，例如 Administration 这个单词就很难快速正确地输入，因此很多用户都会设置
|
||||
|
||||
```
|
||||
alias sl='ls'
|
||||
```
|
||||
|
||||
以及
|
||||
|
||||
```
|
||||
alias gerp='echo "You did it *again*!"; grep'
|
||||
```
|
||||
|
||||
`grep` 命令最基本的用途就是在文件中查找字符串，在熟悉这个命令之后，它一定是最常用的命令之一，因此输入错误导致不得不重输命令就很令人抓狂。
|
||||
|
||||
在上面 `gerp` 的例子中，包含的不只是一条命令，而是两条。第一条命令 `echo "You did it *again*!"` 输出了一条提醒用户拼写错误的消息，然后使用分号（`；`）把两条命令隔开，再往后才是 `grep` 这一条正确的命令。
|
||||
|
||||
在我的系统上使用 `gerp` 来搜索 `/etc/skel/.bashrc` 中包含“alias”这个单词的行，就会输出以下内容：
|
||||
|
||||
```
|
||||
$ gerp -R alias /etc/skel/.bashrc
|
||||
You did it *again*!
|
||||
alias ls='ls --color=auto'
|
||||
alias grep='grep --colour=auto'
|
||||
alias egrep='egrep --colour=auto'
|
||||
alias fgrep='fgrep --colour=auto'
|
||||
alias cp="cp -i"
|
||||
alias df='df -h'
|
||||
alias free='free -m'
|
||||
alias np='nano -w PKGBUILD'
|
||||
alias more=less
|
||||
shopt -s expand_aliases
|
||||
```
|
||||
|
||||
在命令别名中以固定的顺序执行多个命令，甚至更进一步，把多个命令串连起来，让后面的命令可以使用到前面的命令的执行结果。这样的做法已经非常接近 bash 脚本了。这篇文章已经接近尾声，我们将在下一篇文章中详细介绍。
|
||||
|
||||
如果想要删除在终端中临时设置的别名，可以使用 `unalias` 命令。
|
||||
|
||||
```
|
||||
unalias gerp
|
||||
```
|
||||
|
||||
如果想要持久保存命令别名，可以将命令别名放在用户主目录的 `.bashrc` 文件中，具体的方法在[上一篇文章][2]中已经介绍过。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/blog/learn/2018/12/aliases-diy-shell-commands
|
||||
|
||||
作者：[Paul Brown][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[HankChow](https://github.com/HankChow)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.linux.com/users/bro66
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.linux.com/learn/intro-to-linux/2018/7/users-groups-and-other-linux-beasts
|
||||
[2]: https://www.linux.com/blog/learn/2018/12/bash-variables-environmental-and-otherwise
|
||||
|
||||
Loading…
Reference in New Issue
Block a user