mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-16 22:42:21 +08:00
Lv Feng
GitHub
commit
ef0b2c451a
@ -976,7 +976,7 @@ $ python webserver3g.py
|
||||
$ python client3.py --max-clients 128
|
||||
```
|
||||
|
||||
现在来查看一下，确保没有僵尸进程存在。耶！没有僵尸的生活真美好 ^_^
|
||||
现在来查看一下，确保没有僵尸进程存在。耶！没有僵尸的生活真美好 `^_^`。
|
||||
|
||||
|
||||
|
||||
@ -984,7 +984,7 @@ $ python client3.py --max-clients 128
|
||||
|
||||
恭喜！你刚刚经历了一段很长的旅程，我希望你能够喜欢它。现在你拥有了自己的简易并发服务器，并且这段代码能够为你在继续研究生产级 Web 服务器的路上奠定基础。
|
||||
|
||||
我将会留一个作业：你需要将第二部分中的 WSGI 服务器升级，将它改造为一个并发服务器。你可以在[这里][12]找到更改后的代码。但是，当你实现了自己的版本之后，你才应该来看我的代码。你已经拥有了实现这个服务器所需的所有信息。所以，快去实现它吧 ^_^
|
||||
我将会留一个作业：你需要将第二部分中的 WSGI 服务器升级，将它改造为一个并发服务器。你可以在[这里][12]找到更改后的代码。但是，当你实现了自己的版本之后，你才应该来看我的代码。你已经拥有了实现这个服务器所需的所有信息。所以，快去实现它吧 `^_^`。
|
||||
|
||||
然后要做什么呢？乔希·比林斯说过：
|
||||
|
||||
|
||||
@ -0,0 +1,231 @@
|
||||
内容安全策略（CSP），防御 XSS 攻击的好助手
|
||||
=====
|
||||
|
||||
很久之前，我的个人网站被攻击了。我不知道它是如何发生的，但它确实发生了。幸运的是，攻击带来的破坏是很小的：一小段 JavaScript 被注入到了某些页面的底部。我更新了 FTP 和其它的口令，清理了一些文件，事情就这样结束了。
|
||||
|
||||
有一点使我很恼火：在当时，还没有一种简便的方案能够使我知道那里有问题，更重要的是能够保护网站的访客不被这段恼人的代码所扰。
|
||||
|
||||
现在有一种方案出现了，这种技术在上述两方面都十分的成功。它就是内容安全策略（content security policy，CSP）。
|
||||
|
||||
### 什么是 CSP?
|
||||
|
||||
其核心思想十分简单：网站通过发送一个 CSP 头部，来告诉浏览器什么是被授权执行的与什么是需要被禁止的。
|
||||
|
||||
这里有一个 PHP 的例子：
|
||||
|
||||
```
|
||||
<?php
|
||||
header("Content-Security-Policy: <your directives>");
|
||||
?>
|
||||
```
|
||||
|
||||
#### 一些指令
|
||||
|
||||
你可以定义一些全局规则或者定义一些涉及某一类资源的规则：
|
||||
|
||||
```
|
||||
default-src 'self' ;
|
||||
# self = 同端口，同域名，同协议 => 允许
|
||||
```
|
||||
|
||||
基础参数是 `default-src`：如果没有为某一类资源设置指令规则，那么浏览器就会使用这个默认参数值。
|
||||
|
||||
```
|
||||
script-src 'self' www.google-analytics.com ;
|
||||
# 来自这些域名的 JS 文件 => 允许
|
||||
```
|
||||
|
||||
在这个例子中，我们已经授权了 www.google-analytics.com 这个域名来源的 JavaScript 文件使用到我们的网站上。我们也添加了 `'self'` 这个关键词；如果我们通过 `script-src` 来重新设置其它的规则指令，它将会覆盖 `default-src` 规则。
|
||||
|
||||
如果没有指明协议（scheme）或端口，它就会强制选择与当前页面相同的协议或端口。这样做防止了混合内容（LCTT 译注：混合内容指 HTTPS 页面中也有非 HTTPS 资源，可参见： https://developer.mozilla.org/zh-CN/docs/Security/MixedContent ）。如果页面是 https://example.com，那么你将无法加载 http://www.google-analytics.com/file.js 因为它已经被禁止了（协议不匹配）。然而，有一个例外就是协议的提升是被允许的。如果 http://example.com 尝试加载 https://www.google-analytics.com/file.js，接着协议或端口允许被更改以便协议的提升。
|
||||
|
||||
```
|
||||
style-src 'self' data: ;
|
||||
# Data-Uri 嵌入 CSS => 允许
|
||||
```
|
||||
|
||||
在这个例子中，关键词 `data:` 授权了在 CSS 文件中 data 内嵌内容。
|
||||
|
||||
在 CSP 1 规范下，你也可以设置如下规则：
|
||||
|
||||
- `img-src` 有效的图片来源
|
||||
- `connect-src` 应用于 XMLHttpRequest（AJAX），WebSocket 或 EventSource
|
||||
- `font-src` 有效的字体来源
|
||||
- `object-src` 有效的插件来源（例如，`<object>`，`<embed>`，`<applet>`）
|
||||
- `media-src` 有效的 `<audio>` 和 `<video>` 来源
|
||||
|
||||
CSP 2 规范包含了如下规则：
|
||||
|
||||
- `child-src` 有效的 web workers 和 元素来源，如 `<frame>` 和 `<iframe>` （这个指令用来替代 CSP 1 中废弃了的 `frame-src` 指令）
|
||||
- `form-action` 可以作为 HTML `<form>` 的 action 的有效来源
|
||||
- `frame-ancestors` 使用 `<frame>`，`<iframe>`，`<object>`，`<embed>` 或 `<applet>` 内嵌资源的有效来源
|
||||
- `upgrade-insecure-requests` 命令用户代理来重写 URL 协议，将 HTTP 改到 HTTPS （为一些需要重写大量陈旧 URL 的网站提供了方便）。
|
||||
|
||||
为了更好的向后兼容一些废弃的属性，你可以简单的复制当前指令的内容同时为那个废弃的指令创建一个相同的副本。例如，你可以复制 `child-src` 的内容同时在 `frame-src` 中添加一份相同的副本。
|
||||
|
||||
CSP 2 允许你添加路径到白名单中（CSP 1 只允许域名被添加到白名单中）。因此，相较于将整个 www.foo.com 域添加到白名单，你可以通过添加 www.foo.com/some/folder 这样的路径到白名单中来作更多的限制。这个需要浏览器中 CSP 2 的支持，但它很明显更安全。
|
||||
|
||||
#### 一个例子
|
||||
|
||||
我为 Web 2015 巴黎大会上我的演讲 “[CSP in Action][1]”制作了一个简单的例子。
|
||||
|
||||
在没有 CSP 的情况下，页面展示如下图所示：
|
||||
|
||||
|
||||
|
||||
不是十分优美。要是我们启用了如下的 CSP 指令又会怎样呢？
|
||||
|
||||
```
|
||||
<?php
|
||||
header("Content-Security-Policy:
|
||||
default-src 'self' ;
|
||||
script-src 'self' www.google-analytics.com stats.g.doubleclick.net ;
|
||||
style-src 'self' data: ;
|
||||
img-src 'self' www.google-analytics.com stats.g.doubleclick.net data: ;
|
||||
frame-src 'self' ;");
|
||||
?>
|
||||
```
|
||||
|
||||
浏览器将会作什么呢？它会（非常严格的）在 CSP 基础规则之下应用这些指令，这意味着**任何没有在 CSP 指令中被授权允许的都将会被禁止**（“blocked” 指的是不被执行、不被显示并且不被使用在网站中）。
|
||||
|
||||
在 CSP 的默认设置中，内联脚本和样式是不被授权的，意味着每一个 `<script>`，`onclick` 事件属性或 `style` 属性都将会被禁止。你可以使用 `style-src 'unsafe-inline' ;` 指令来授权使用内联 CSS。
|
||||
|
||||
在一个支持 CSP 的现代浏览器中，上述示例看起来如下图：
|
||||
|
||||
|
||||
|
||||
发生了什么？浏览器应用了指令并且拒绝了所有没有被授权的内容。它在浏览器调试终端中发送了这些通知：
|
||||
|
||||
|
||||
|
||||
如果你依然不确定 CSP 的价值，请看一下 Aaron Gustafson 文章 “[More Proof We Don't Control Our Web Pages][2]”。
|
||||
|
||||
当然，你可以使用比我们在示例中提供的更严格的指令：
|
||||
|
||||
- 设置 `default-src` 为 'none'
|
||||
- 为每条规则指定你的设置
|
||||
- 为请求的文件指定它的绝对路径
|
||||
- 等
|
||||
|
||||
### 更多关于 CSP 的信息
|
||||
|
||||
#### 支持
|
||||
|
||||
CSP 不是一个需要复杂的配置才能正常工作的每日构建特性。CSP 1 和 2 是候选推荐标准！[浏览器可以非常完美的支持 CSP 1][3]。
|
||||
|
||||
|
||||
|
||||
[CSP 2 是较新的规范][4]，因此对它的支持会少那么一点。
|
||||
|
||||
|
||||
|
||||
现在 CSP 3 还是一个早期草案，因此还没有被支持，但是你依然可以使用 CSP 1 和 2 来做一些重大的事。
|
||||
|
||||
#### 其他需要考虑的因素
|
||||
|
||||
CSP 被设计用来降低跨站脚本攻击（XSS）的风险，这就是不建议开启内联脚本和 `script-src` 指令的原因。Firefox 对这个问题做了很好的说明：在浏览器中，敲击 `Shift + F2` 并且键入 `security csp`，它就会向你展示指令和对应的建议。这里有一个在 Twitter 网站中应用的例子：
|
||||
|
||||
|
||||
|
||||
如果你确实需要使用内联脚本和样式的话，另一种可能就是生成一份散列值。例如，我们假定你需要使用如下的内联脚本：
|
||||
|
||||
```
|
||||
<script>alert('Hello, world.');</script>
|
||||
```
|
||||
|
||||
你应该在 `script-src` 指令中添加 `sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng=` 作为有效来源。这个散列值用下面的 PHP 脚本执行获得的结果：
|
||||
|
||||
```
|
||||
<?php
|
||||
echo base64_encode(hash('sha256', "alert('Hello, world.');", true));
|
||||
?>
|
||||
```
|
||||
|
||||
我在前文中说过 CSP 被设计用来降低 XSS 风险，我还得加上“……与降低未经请求内容的风险。”伴随着 CSP 的使用，你必须**知道你内容的来源是哪里**与**它们在你的前端都作了些什么**（内联样式，等）。CSP 同时可以帮助你让贡献者、开发人员和其他人员来遵循你内容来源的规则！
|
||||
|
||||
现在你的问题就只是，“不错，这很好，但是我们如何在生产环境中使用它呢？”
|
||||
|
||||
### 如何在现实世界中使用它
|
||||
|
||||
想要在第一次使用 CSP 之后就失望透顶的方法就是在生产环境中测试。不要想当然的认为，“这会很简单。我的代码是完美并且相当清晰的。”不要这样作。我这样干过。相信我，这相当的蠢。
|
||||
|
||||
正如我之前说明的，CSP 指令由 CSP 头部来激活，这中间没有过渡阶段。你恰恰就是其中的薄弱环节。你可能会忘记授权某些东西或者遗忘了你网站中的一小段代码。CSP 不会饶恕你的疏忽。然而，CSP 的两个特性将这个问题变得相当的简单。
|
||||
|
||||
#### report-uri
|
||||
|
||||
还记得 CSP 发送到终端中的那些通知么？`report-uri` 指令可以被用来告诉浏览器发送那些通知到指定的地址。报告以 JSON 格式送出。
|
||||
|
||||
```
|
||||
report-uri /csp-parser.php ;
|
||||
```
|
||||
|
||||
因此，我们可以在 csp-parser.php 文件中处理有浏览器送出的数据。这里有一个由 PHP 实现的最基础的例子：
|
||||
|
||||
```
|
||||
$data = file_get_contents('php://input');
|
||||
|
||||
if ($data = json_decode($data, true)) {
|
||||
$data = json_encode(
|
||||
$data,
|
||||
JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES
|
||||
);
|
||||
mail(EMAIL, SUBJECT, $data);
|
||||
}
|
||||
```
|
||||
|
||||
这个通知将会被转换成为一封邮件。在开发过程中，你可能不会需要比这更复杂的其它东西。
|
||||
|
||||
对于一个生产环境（或者是一个有较多访问的开发环境），你应该使用一种比邮件更好的收集信息的方式，因为这种方式在节点上没有验证和速率限制，并且 CSP 可能变得乱哄哄的。只需想像一个会产生 100 个 CSP 通知（例如，一个从未授权来源展示图片的脚本）并且每天会被浏览 100 次的页面，那你就会每天收到 10000 个通知啊！
|
||||
|
||||
例如 [report-uri.io](https://report-uri.io/) 这样的服务可以用来简化你的通知管理。你也可以在 GitHub上看一些另外的使用 `report-uri` （与数据库搭配，添加一些优化，等）的简单例子。
|
||||
|
||||
### report-only
|
||||
|
||||
正如我们所见的，最大的问题就是在使用和不使用 CSP 之间没有中间地带。然而，一个名为 `report-only` 的特性会发送一个稍有不同的头部：
|
||||
|
||||
```
|
||||
<?php
|
||||
header("Content-Security-Policy-Report-Only: <your directives>");
|
||||
?>
|
||||
```
|
||||
|
||||
总的来说，这个头部就是告诉浏览器，“表现得似乎所有的 CSP 指令都被应用了，但是不禁止任何东西。只是发送通知给自己。”这是一种相当棒的测试指令的方式，避免了任何有价值的东西被禁止的风险。
|
||||
|
||||
在 `report-only` 和 `report-uri` 的帮助下你可以毫无风险的测试 CSP 指令，并且可以实时的监控网站上一切与 CSP 相关的内容。这两个特性对部署和维护 CSP 来说真是相当的有用！
|
||||
|
||||
### 结论
|
||||
|
||||
#### 为什么 CSP 很酷
|
||||
|
||||
CSP 对你的用户来说是尤其重要的：他们在你的网站上不再需要遭受任何的未经请求的脚本，内容或 XSS 的威胁了。
|
||||
|
||||
对于网站维护者来说 CSP 最重要的优势就是可感知。如果你对图片来源设置了严格的规则，这时一个脚本小子尝试在你的网站上插入一张未授权来源的图片，那么这张图片就会被禁止，并且你会在第一时间收到提醒。
|
||||
|
||||
开发者也需要确切的知道他们的前端代码都在做些什么，CSP 可以帮助他们掌控一切。会促使他们去重构他们代码中的某些部分（避免内联函数和样式，等）并且促使他们遵循最佳实践。
|
||||
|
||||
#### 如何让 CSP 变得更酷
|
||||
|
||||
讽刺的是，CSP 在一些浏览器中过分的高效了，在和书签栏小程序一起使用时会产生一些 bug。因此，不要更新你的 CSP 指令来允许书签栏小程序。我们无法单独的责备任何一个浏览器；它们都有些问题：
|
||||
|
||||
- Firefox
|
||||
- Chrome (Blink)
|
||||
- WebKit
|
||||
|
||||
大多数情况下，这些 bug 都是禁止通知中的误报。所有的浏览器提供者都在努力解决这些问题，因此我们可以期待很快就会被解决。无论怎样，这都不会成为你使用 CSP 的绊脚石。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.smashingmagazine.com/2016/09/content-security-policy-your-future-best-friend/
|
||||
|
||||
作者：[Nicolas Hoffmann][a]
|
||||
译者：[wcnnbdk1](https://github.com/wcnnbdk1)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.smashingmagazine.com/author/nicolashoffmann/
|
||||
[1]: https://rocssti.net/en/example-csp-paris-web2015
|
||||
[2]: https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/
|
||||
[3]: http://caniuse.com/#feat=contentsecuritypolicy
|
||||
[4]: http://caniuse.com/#feat=contentsecuritypolicy2
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
lujianbo
|
||||
|
||||
How to Setup Pfsense Firewall and Basic Configuration
|
||||
================================================================================
|
||||
In this article our focus is Pfsense setup, basic configuration and overview of features available in the security distribution of FreeBSD. In this tutorial we will run network wizard for basic setting of firewall and detailed overview of services. After the [installation process][1] following snapshot shows the IP addresses of WAN/LAN and different options for the management of Pfsense firewall.
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
Translating by cposture
|
||||
Python unittest: assertTrue is truthy, assertFalse is falsy
|
||||
===========================
|
||||
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
Translating by ivo-wang
|
||||
Microfluidic cooling may prevent the demise of Moore's Law
|
||||
============================================================
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
translated by pspkforever
|
||||
translated by pspkforever,now Firstadream
|
||||
DOCKER DATACENTER IN AWS AND AZURE IN A FEW CLICKS
|
||||
===================================================
|
||||
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
(翻译中 by runningwater)
|
||||
CANONICAL CONSIDERING TO DROP 32 BIT SUPPORT IN UBUNTU
|
||||
========================================================
|
||||
|
||||
@ -30,7 +29,7 @@ I understand why they need to make this move from a security standpoint, but it
|
||||
via: https://itsfoss.com/ubuntu-32-bit-support-drop/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ItsFoss+%28Its+FOSS%21+An+Open+Source+Blog%29
|
||||
|
||||
作者：[John Paul][a]
|
||||
译者：[runningwater](https://github.com/runningwater)
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,86 +0,0 @@
|
||||
sevenot translating
|
||||
Terminator A Linux Terminal Emulator With Multiple Terminals In One Window
|
||||
=============================================================================
|
||||
|
||||
|
||||
|
||||
Each Linux distribution has a default terminal emulator for interacting with system through commands. But the default terminal app might not be perfect for you. There are so many terminal apps that will provide you more functionalities to perform more tasks simultaneously to sky-rocket speed of your work. Such useful terminal emulators include Terminator, a multi-windows supported free terminal emulator for your Linux system.
|
||||
|
||||
### What Is Linux Terminal Emulator?
|
||||
|
||||
A Linux terminal emulator is a program that lets you interact with the shell. All Linux distributions come with a default Linux terminal app that let you pass commands to the shell.
|
||||
|
||||
### Terminator, A Free Linux Terminal App
|
||||
|
||||
Terminator is a Linux terminal emulator that provides several features that your default terminal app does not support. It provides the ability to create multiple terminals in one window and faster your work progress. Other than multiple windows, it allows you to change other properties such as, terminal fonts, fonts colour, background colour and so on. Let's see how we can install and use Terminator in different Linux distributions.
|
||||
|
||||
### How To Install Terminator In Linux?
|
||||
|
||||
#### Install Terminator In Ubuntu Based Distributions
|
||||
|
||||
Terminator is available in the default Ubuntu repository. So you don't require to add any additional PPA. Just use APT or Software App to install it in Ubuntu.
|
||||
|
||||
```
|
||||
sudo apt-get install terminator
|
||||
```
|
||||
|
||||
In case Terminator is not available in your default repository, just compile Terminator from source code.
|
||||
|
||||
[DOWNLOAD SOURCE CODE][1]
|
||||
|
||||
Download Terminator source code and extract it on your desktop. Now open your default terminal & cd into the extracted folder.
|
||||
|
||||
Now use the following command to install Terminator -
|
||||
|
||||
```
|
||||
sudo ./setup.py install
|
||||
```
|
||||
|
||||
#### Install Terminator In Fedora & Other Derivatives
|
||||
|
||||
```
|
||||
dnf install terminator
|
||||
```
|
||||
|
||||
#### Install Terminator In OpenSuse
|
||||
|
||||
[INSTALL IN OPENSUSE][2]
|
||||
|
||||
### How To Use Multiple Terminals In One Window?
|
||||
|
||||
After you have installed Terminator, simply open multiple terminals in one window. Simply right click and divide.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
You can create as many terminals as you want, if you can manage them.
|
||||
|
||||
|
||||
|
||||
### Customise Terminals
|
||||
|
||||
Right click the terminal and click Properties. Now you can customise fonts, fonts colour, title colour & background and terminal fonts colour & background.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Conclusion & What Is Your Favorite Terminal Emulator?
|
||||
|
||||
Terminator is an advanced terminal emulator and it also let you customize the interface. If you have not yet switched from your default terminal emulator then just try this one. I know you'll like it. If you're using any other free terminal emulator, then let us know your favorite terminal emulator. Also don't forget to share this article with your friends. Perhaps your friends are searching for something like this.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/mandatory-access-control-with-selinux-or-apparmor-linux/
|
||||
|
||||
作者：[author][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: http://www.linuxandubuntu.com/home/terminator-a-linux-terminal-emulator-with-multiple-terminals-in-one-window
|
||||
[1]: https://launchpad.net/terminator/+download
|
||||
[2]: http://software.opensuse.org/download.html?project=home%3AKorbi123&package=terminator
|
||||
@ -1,4 +1,3 @@
|
||||
Translating by Flowsnow!
|
||||
Best Password Manager — For Windows, Linux, Mac, Android, iOS and Enterprise
|
||||
==============================
|
||||
|
||||
|
||||
@ -1,4 +1,5 @@
|
||||
ch_cn translating
|
||||
OneNewLife Translating
|
||||
|
||||
Introducing React Native Ubuntu
|
||||
=====================
|
||||
|
||||
|
||||
@ -1,5 +1,4 @@
|
||||
hkurj translating
|
||||
I Best Modern Linux ‘init’ Systems (1992-2015)
|
||||
5 Best Modern Linux ‘init’ Systems (1992-2015)
|
||||
============================================
|
||||
|
||||
In Linux and other Unix-like operating systems, the init (initialization) process is the first process executed by the kernel at boot time. It has a process ID (PID) of 1, it is executed in the background until the system is shut down.
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
Translating by cposture
|
||||
How to Mount Remote Linux Filesystem or Directory Using SSHFS Over SSH
|
||||
============================
|
||||
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
JianhuanZhuo
|
||||
|
||||
Building a Real-Time Recommendation Engine with Data Science
|
||||
======================
|
||||
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
Tranlating by lengmi.
|
||||
Building your first Atom plugin
|
||||
=====
|
||||
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
chisper is translating.
|
||||
|
||||
A Raspberry Pi Hadoop Cluster with Apache Spark on YARN: Big Data 101
|
||||
======
|
||||
|
||||
|
||||
@ -1,258 +0,0 @@
|
||||
wcnnbdk1 Translating
|
||||
Content Security Policy, Your Future Best Friend
|
||||
=====
|
||||
|
||||
A long time ago, my personal website was attacked. I do not know how it happened, but it happened. Fortunately, the damage from the attack was quite minor: A piece of JavaScript was inserted at the bottom of some pages. I updated the FTP and other credentials, cleaned up some files, and that was that.
|
||||
|
||||
One point made me mad: At the time, there was no simple solution that could have informed me there was a problem and — more importantly — that could have protected the website’s visitors from this annoying piece of code.
|
||||
|
||||
A solution exists now, and it is a technology that succeeds in both roles. Its name is content security policy (CSP).
|
||||
|
||||
### What Is A CSP? Link
|
||||
|
||||
The idea is quite simple: By sending a CSP header from a website, you are telling the browser what it is authorized to execute and what it is authorized to block.
|
||||
|
||||
Here is an example with PHP:
|
||||
|
||||
```
|
||||
<?php
|
||||
header("Content-Security-Policy: <your directives>");
|
||||
?>
|
||||
```
|
||||
|
||||
#### SOME DIRECTIVES LINK
|
||||
|
||||
You may define global rules or define rules related to a type of asset:
|
||||
|
||||
```
|
||||
default-src 'self' ;
|
||||
# self = same port, same domain name, same protocol => OK
|
||||
```
|
||||
|
||||
The base argument is default-src: If no directive is defined for a type of asset, then the browser will use this value.
|
||||
|
||||
```
|
||||
script-src 'self' www.google-analytics.com ;
|
||||
# JS files on these domains => OK
|
||||
```
|
||||
|
||||
In this example, we’ve authorized the domain name www.google-analytics.com as a source of JavaScript files to use on our website. We’ve added the keyword 'self'; if we redefined the directive script-src with another rule, it would override default-src rules.
|
||||
|
||||
If no scheme or port is specified, then it enforces the same scheme or port from the current page. This prevents mixed content. If the page is https://example.com, then you wouldn’t be able to load http://www.google-analytics.com/file.js because it would be blocked (the scheme wouldn’t match). However, there is an exception to allow a scheme upgrade. If http://example.com tries to load https://www.google-analytics.com/file.js, then the scheme or port would be allowed to change to facilitate the scheme upgrade.
|
||||
|
||||
```
|
||||
style-src 'self' data: ;
|
||||
# Data-Uri in a CSS => OK
|
||||
```
|
||||
|
||||
In this example, the keyword data: authorizes embedded content in CSS files.
|
||||
|
||||
Under the CSP level 1 specification, you may also define rules for the following:
|
||||
|
||||
- `img-src`
|
||||
|
||||
valid sources of images
|
||||
|
||||
- `connect-src`
|
||||
|
||||
applies to XMLHttpRequest (AJAX), WebSocket or EventSource
|
||||
|
||||
- `font-src`
|
||||
|
||||
valid sources of fonts
|
||||
|
||||
- `object-src`
|
||||
|
||||
valid sources of plugins (for example, `<object>, <embed>, <applet>`)
|
||||
|
||||
- `media-src`
|
||||
|
||||
valid sources of `<audio> and <video>`
|
||||
|
||||
|
||||
CSP level 2 rules include the following:
|
||||
|
||||
- `child-src`
|
||||
|
||||
valid sources of web workers and elements such as `<frame>` and `<iframe>` (this replaces the deprecated frame-src from CSP level 1)
|
||||
|
||||
- `form-action`
|
||||
|
||||
valid sources that can be used as an HTML `<form>` action
|
||||
|
||||
- `frame-ancestors`
|
||||
|
||||
valid sources for embedding the resource using `<frame>, <iframe>, <object>, <embed> or <applet>`.
|
||||
|
||||
- `upgrade-insecure-requests`
|
||||
|
||||
instructs user agents to rewrite URL schemes, changing HTTP to HTTPS (for websites with a lot of old URLs that need to be rewritten).
|
||||
|
||||
For better backwards-compatibility with deprecated properties, you may simply copy the contents of the actual directive and duplicate them in the deprecated one. For example, you may copy the contents of child-src and duplicate them in frame-src.
|
||||
|
||||
CSP 2 allows you to whitelist paths (CSP 1 allows only domains to be whitelisted). So, rather than whitelisting all of www.foo.com, you could whitelist www.foo.com/some/folder to restrict it further. This does require CSP 2 support in the browser, but it is obviously more secure.
|
||||
|
||||
#### AN EXAMPLE
|
||||
|
||||
I made a simple example for the Paris Web 2015 conference, where I presented a talk entitled “[CSP in Action][1].”
|
||||
Without CSP, the page would look like this:
|
||||
|
||||
|
||||
|
||||
Not very nice. What if we enabled the following CSP directives?
|
||||
|
||||
```
|
||||
<?php
|
||||
header("Content-Security-Policy:
|
||||
default-src 'self' ;
|
||||
script-src 'self' www.google-analytics.com stats.g.doubleclick.net ;
|
||||
style-src 'self' data: ;
|
||||
img-src 'self' www.google-analytics.com stats.g.doubleclick.net data: ;
|
||||
frame-src 'self' ;");
|
||||
?>
|
||||
```
|
||||
|
||||
What would the browser do? It would (very strictly) apply these directives under the primary rule of CSP, which is that anything not authorized in a CSP directive will be blocked (“blocked” meaning not executed, not displayed and not used by the website).
|
||||
|
||||
By default in CSP, inline scripts and styles are not authorized, which means that every `<script>`, onclick or style attribute will be blocked. You could authorize inline CSS with style-src 'unsafe-inline' ;.
|
||||
|
||||
In a modern browser with CSP support, the example would look like this:
|
||||
|
||||
|
||||
|
||||
What happened? The browser applied the directives and rejected anything that was not authorized. It sent these notifications to the console:
|
||||
|
||||
|
||||
|
||||
If you’re still not convinced of the value of CSP, have a look at Aaron Gustafson’s article “[More Proof We Don’t Control Our Web Pages][2].”
|
||||
|
||||
Of course, you may use stricter directives than the ones in the example provided above:
|
||||
|
||||
- set default-src to 'none',
|
||||
- specify what you need for each rule,
|
||||
- specify the exact paths of required files,
|
||||
- etc.
|
||||
|
||||
|
||||
### More Information On CSP
|
||||
|
||||
#### SUPPORT
|
||||
|
||||
CSP is not a nightly feature requiring three flags to be activated in order for it to work. CSP levels 1 and 2 are candidate recommendations! [Browser support for CSP level 1][3] is excellent.
|
||||
|
||||
|
||||
|
||||
The [level 2 specification][4] is more recent, so it is a bit less supported.
|
||||
|
||||
|
||||
|
||||
CSP level 3 is an early draft now, so it is not yet supported, but you can already do great things with levels 1 and 2.
|
||||
|
||||
#### OTHER CONSIDERATIONS
|
||||
|
||||
CSP has been designed to reduce cross-site scripting (XSS) risks, which is why enabling inline scripts in script-src directives is not recommended. Firefox illustrates this issue very nicely: In the browser, hit Shift + F2 and type security csp, and it will show you directives and advice. For example, here it is used on Twitter’s website:
|
||||
|
||||
|
||||
|
||||
Another possibility for inline scripts or inline styles, if you really have to use them, is to create a hash value. For example, suppose you need to have this inline script:
|
||||
|
||||
```
|
||||
<script>alert('Hello, world.');</script>
|
||||
```
|
||||
|
||||
You might add 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng=' as a valid source in your script-src directives. The hash generated is the result of this in PHP:
|
||||
|
||||
```
|
||||
<?php
|
||||
echo base64_encode(hash('sha256', "alert('Hello, world.');", true));
|
||||
?>
|
||||
```
|
||||
|
||||
I said earlier that CSP is designed to reduce XSS risks — I could have added, “… and reduce the risks of unsolicited content.” With CSP, you have to know where your sources of content are and what they are doing on your front end (inline styles, etc.). CSP can also help you force contributors, developers and others to respect your rules about sources of content!
|
||||
|
||||
Now your question is, “OK, this is great, but how do we use it in a production environment?”
|
||||
|
||||
### How To Use It In The Real World
|
||||
|
||||
The easiest way to get discouraged with using CSP the first time is to test it in a live environment, thinking, “This will be easy. My code is bad ass and perfectly clean.” Don’t do this. I did it. It’s stupid, trust me.
|
||||
|
||||
As I explained, CSP directives are activated with a CSP header — there is no middle ground. You are the weak link here. You might forget to authorize something or forget a piece of code on your website. CSP will not forgive your oversight. However, two features of CSP greatly simplify this problem.
|
||||
|
||||
#### REPORT-URI
|
||||
|
||||
Remember the notifications that CSP sends to the console? The directive report-uri can be used to tell the browser to send them to the specified address. Reports are sent in JSON format.
|
||||
|
||||
```
|
||||
report-uri /csp-parser.php ;
|
||||
```
|
||||
|
||||
So, in the csp-parser.php file, we can process the data sent by the browser. Here is the most basic example in PHP:
|
||||
|
||||
```
|
||||
$data = file_get_contents('php://input');
|
||||
|
||||
if ($data = json_decode($data, true)) {
|
||||
$data = json_encode(
|
||||
$data,
|
||||
JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES
|
||||
);
|
||||
mail(EMAIL, SUBJECT, $data);
|
||||
}
|
||||
```
|
||||
|
||||
This notification will be transformed into an email. During development, you might not need anything more complex than this.
|
||||
|
||||
For a production environment (or a more visited development environment), you’d better use a way other than email to collect information, because there is no auth or rate limiting on the endpoint, and CSP can be very noisy. Just imagine a page that generates 100 CSP notifications (for example, a script that display images from an unauthorized source) and that is viewed 100 times a day — you could get 10,000 notifications a day!
|
||||
|
||||
A service such as report-uri.io can be used to simplify the management of reporting. You can see other simple examples for report-uri (with a database, with some optimizations, etc.) on GitHub.
|
||||
|
||||
### REPORT-ONLY
|
||||
|
||||
As we have seen, the biggest issue is that there is no middle ground between CSP being enabled and disabled. However, a feature named report-only sends a slightly different header:
|
||||
|
||||
```
|
||||
<?php
|
||||
header("Content-Security-Policy-Report-Only: <your directives>");
|
||||
?>
|
||||
```
|
||||
|
||||
Basically, this tells the browser, “Act as if these CSP directives were being applied, but do not block anything. Just send me the notifications.” It is a great way to test directives without the risk of blocking any required assets.
|
||||
|
||||
With report-only and report-uri, you can test CSP directives with no risk, and you can monitor in real time everything CSP-related on a website. These two features are really powerful for deploying and maintaining CSP!
|
||||
|
||||
### Conclusion
|
||||
|
||||
#### WHY CSP IS COOL
|
||||
|
||||
CSP is most important for your users: They don’t have to suffer any unsolicited scripts or content or XSS vulnerabilities on your website.
|
||||
|
||||
The most important advantage of CSP for website maintainers is awareness. If you’ve set strict rules for image sources, and a script kiddie attempts to insert an image on your website from an unauthorized source, that image will be blocked, and you will be notified instantly.
|
||||
|
||||
Developers, meanwhile, need to know exactly what their front-end code does, and CSP helps them master that. They will be prompted to refactor parts of their code (avoiding inline functions and styles, etc.) and to follow best practices.
|
||||
|
||||
#### HOW CSP COULD BE EVEN COOLER LINK
|
||||
|
||||
Ironically, CSP is too efficient in some browsers — it creates bugs with bookmarklets. So, do not update your CSP directives to allow bookmarklets. We can’t blame any one browser in particular; all of them have issues:
|
||||
|
||||
- Firefox
|
||||
- Chrome (Blink)
|
||||
- WebKit
|
||||
|
||||
Most of the time, the bugs are false positives in blocked notifications. All browser vendors are working on these issues, so we can expect fixes soon. Anyway, this should not stop you from using CSP.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.smashingmagazine.com/2016/09/content-security-policy-your-future-best-friend/?utm_source=webopsweekly&utm_medium=email
|
||||
|
||||
作者：[Nicolas Hoffmann][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.smashingmagazine.com/author/nicolashoffmann/
|
||||
[1]: https://rocssti.net/en/example-csp-paris-web2015
|
||||
[2]: https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/
|
||||
[3]: http://caniuse.com/#feat=contentsecuritypolicy
|
||||
[4]: http://caniuse.com/#feat=contentsecuritypolicy2
|
||||
|
||||
@ -1,96 +0,0 @@
|
||||
jiajia9linuxer
|
||||
The Five Principles of Monitoring Microservices
|
||||
====
|
||||
|
||||
|
||||
|
||||
The need for microservices can be summed up in just one word: speed. The need to deliver more functionality and reliability faster has revolutionized the way developers create software. Not surprisingly, this change has caused ripple effects within software management, including monitoring systems. In this post, we’ll focus on the radical changes required to monitor your microservices in production efficiently. We’ll lay out five guiding principles for adapting your monitoring approach for this new software architecture.
|
||||
|
||||
Monitoring is a critical piece of the control systems of microservices, as the more complex your software gets, the harder it is to understand its performance and troubleshoot problems. Given the dramatic changes to software delivery, however, monitoring needs an overhaul to perform well in a microservice environment. The rest of this article presents the five principles of monitoring microservices, as follows:
|
||||
|
||||
1. Monitor containers and what’s inside them.
|
||||
2. Alert on service performance, not container performance.
|
||||
3. Monitor services that are elastic and multi-location.
|
||||
4. Monitor APIs.
|
||||
5. Map your monitoring to your organizational structure.
|
||||
|
||||
Leveraging these five principles will allow you to establish more effective monitoring as you make your way towards microservices. These principles will allow you to address both the technological changes associated with microservices, in addition to the organizational changes related to them.
|
||||
|
||||
### The Principles of Microservice Monitoring
|
||||
|
||||
#### 1. Monitor Containers and What’s Running Inside Them
|
||||
|
||||
Containers gained prominence as the building blocks of microservices. The speed, portability, and isolation of containers made it easy for developers to embrace a microservice model. There’s been a lot written on the benefits of containers so we won’t recount it all here.
|
||||
|
||||
Containers are black boxes to most systems that live around them. That’s incredibly useful for development, enabling a high level of portability from development through production, from developer laptop to cloud. But when it comes to operating, monitoring and troubleshooting a service, black boxes make common activities harder, leading us to wonder: what’s running in the container? How is the application/code performing? Is it spitting out important custom metrics? From the DevOps perspective, you need deep visibility inside containers rather than just knowing that some containers exist.
|
||||
|
||||
|
||||
|
||||
The typical process for instrumentation in a non-containerized environment — an agent that lives in the user space of a host or VM — doesn’t work particularly well for containers. That’s because containers benefit from being small, isolated processes with as few dependencies as possible.
|
||||
|
||||
And, at scale, running thousands of monitoring agents for even a modestly-sized deployment is an expensive use of resources and an orchestration nightmare. Two potential solutions arise for containers: 1) ask your developers to instrument their code directly, or 2) leverage a universal kernel-level instrumentation approach to see all application and container activity on your hosts. We won’t go into depth here, but each method has pros and cons.
|
||||
|
||||
#### 2. Leverage Orchestration Systems to Alert on Service Performance
|
||||
|
||||
Making sense of operational data in a containerized environment is a new challenge. The metrics of a single container have a much lower marginal value than the aggregate information from all the containers that make up a function or a service.
|
||||
|
||||
This particularly applies to application-level information, like which queries have the slowest response times or which URLs are seeing the most errors, but also applies to infrastructure-level monitoring, like which services’ containers are using the most resources beyond their allocated CPU shares.
|
||||
|
||||
Increasingly, software deployment requires an orchestration system to “translate” a logical application blueprint into physical containers. Common orchestration systems include Kubernetes, Mesosphere DC/OS and Docker Swarm. Teams use an orchestration system to (1) define your microservices and (2) understand the current state of each service in deployment. You could argue that the orchestration system is even more important than the containers. The actual containers are ephemeral — they matter only for the short time that they exist — while your services matter for the life of their usefulness.
|
||||
|
||||
DevOps teams should redefine alerts to focus on characteristics that get as close to monitoring the experience of the service as possible. These alerts are the first line of defense in assessing if something is impacting the application. But getting to these alerts is challenging, if not impossible unless your monitoring system is container-native.
|
||||
|
||||
Container-native solutions leverage orchestration metadata to dynamically aggregate container and application data and calculate monitoring metrics on a per-service basis. Depending on your orchestration tool, you might have different layers of a hierarchy that you’d like to drill into. For example, in Kubernetes, you typically have a Namespace, ReplicaSets, Pods and some containers. Aggregating at these various layers is essential for logical troubleshooting, regardless of the physical deployment of the containers that make up the service.
|
||||
|
||||
|
||||
|
||||
#### 3. Be Prepared for Services that are Elastic and Multi-Location
|
||||
|
||||
Elastic services are certainly not a new concept, but the velocity of change is much faster in container-native environments than virtualized environments. Rapidly changing environments can wreak havoc on brittle monitoring systems.
|
||||
|
||||
Frequently monitoring legacy systems required manual tuning of metrics and checks based on individual deployments of software. This tuning can be as specific as defining the individual metrics to be captured, or configuring collection based on what application is operating in a particular container. While that may be acceptable on a small scale (think tens of containers), it would be unbearable in anything larger. Microservice focused monitoring must be able to comfortably grow and shrink in step with elastic services, without human intervention.
|
||||
|
||||
For example, if the DevOps team must manually define what service a container is included in for monitoring purposes, they no doubt drop the ball as Kubernetes or Mesos spins up new containers regularly throughout the day. Similarly, if Ops were required to install a custom stats endpoint when new code is built and pushed into production, challenges may arise as developers pull base images from a Docker registry.
|
||||
|
||||
In production, build monitoring toward a sophisticated deployment that spans multiple data centers or multiple clouds. Leveraging, for example, AWS CloudWatch will only get you so far if your services span your private data center as well as AWS. That leads back to implementing a monitoring system that can span these different locations as well as operate in dynamic, container-native environments.
|
||||
|
||||
#### 4. Monitor APIs
|
||||
|
||||
In microservice environments, APIs are the lingua franca. They are essentially the only elements of a service that are exposed to other teams. In fact, response and consistency of the API may be the “internal SLA” even if there isn’t a formal SLA defined.
|
||||
|
||||
As a result, API monitoring is essential. API monitoring can take many forms but clearly, must go beyond binary up/down checks. For instance, it’s valuable to understand the most frequently used endpoints as a function of time. This allows teams to see if anything noticeable has changed in the usage of services, whether it be due to a design change or a user change.
|
||||
|
||||
You can also consider the slowest endpoints of your service, as these can reveal significant problems, or, at the very least, point to areas that need the most optimization in your system.
|
||||
|
||||
Finally, the ability to trace service calls through your system represents another critical capability. While typically used by developers, this type of profiling will help you understand the overall user experience while breaking information down into infrastructure and application-based views of your environment.
|
||||
|
||||
#### 5. Map Monitoring to Your Organizational Structure
|
||||
|
||||
While most of this post has been focused on the technological shift in microservices and monitoring, like any technology story, this is as much about people as it is about software bits.
|
||||
|
||||
For those of you familiar with Conway’s law, he reminds us that the design of systems is defined by the organizational structure of the teams building them. The allure of creating faster, more agile software has pushed teams to think about restructuring their development organization and the rules that govern it.
|
||||
|
||||
|
||||
|
||||
So if an organization wants to benefit from this new software architecture approach, their teams must, therefore, mirror microservices themselves. That means smaller teams, loosely coupled; that can choose their direction as long as it still meets the needs of the whole. Within each team, there is more control than ever over languages used, how bugs are handled, or even operational responsibilities.
|
||||
|
||||
DevOps teams can enable a monitoring platform that does exactly this: allows each microservice team to isolate their alerts, metrics, and dashboards, while still giving operations a view into the global system.
|
||||
|
||||
### Conclusion
|
||||
|
||||
There’s one, clear trigger event that precipitated the move to microservices: speed. Organizations wanted to deliver more capabilities to their customers in less time. Once this happened, technology stepped in, the architectural move to micro-services and the underlying shift to containers make speed happen. Anything that gets in the way of this progress train is going to get run over on the tracks.
|
||||
|
||||
As a result, the fundamental principles of monitoring need to adapt to the underlying technology and organizational changes that accompany microservices. Operations teams that recognize this shift can adapt to microservices earlier and easier.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://linoxide.com/firewall/pfsense-setup-basic-configuration/
|
||||
|
||||
作者：[Apurva Dave][a] [Loris Degioanni][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: http://thenewstack.io/author/apurvadave/
|
||||
[b]: http://thenewstack.io/author/lorisdegioanni/
|
||||
@ -1,160 +0,0 @@
|
||||
jiajia9linuxer
|
||||
Using Ansible to Provision Vagrant Boxes
|
||||
====
|
||||
|
||||
|
||||
|
||||
Ansible is a great tool for system administrators who want to automate system administration tasks. From configuration management to provisioning and managing containers for application deployments, Ansible [makes it easy][1]. The lightweight module based architecture is ideal for system administration. One advantage is that when the node is not being managed by Ansible, no resources are used.
|
||||
|
||||
This article covers how to use Ansible to provision Vagrant boxes. A [Vagrant box][2] in simple terms is a virtual machine prepackaged with tools required to run the development environment. You can use these boxes to distribute the development environment used by other team members for project work. Using Ansible, you can automate provisioning the Vagrant boxes with your development packages.
|
||||
|
||||
This tutorial uses Fedora 24 as the host system and [CentOS][3] 7 as the Vagrant box.
|
||||
|
||||
### Setting up prerequisites
|
||||
|
||||
To configure Vagrant boxes using Ansible, you’ll need a few things setup. This tutorial requires you to install Ansible and Vagrant on the host machine. On your host machine, execute the following command to install the tools:
|
||||
|
||||
```
|
||||
sudo dnf install ansible vagrant vagrant-libvirt
|
||||
```
|
||||
|
||||
The above command installs both Ansible and Vagrant on your host system, along with Vagrant’s libvirt provider. Vagrant doesn’t provide functionality to host your virtual machine guests (VMs). Rather, it depends on third party providers such as libvirt, VirtualBox, VMWare, etc. to host the VMs. This provider works directly with libvirt and KVM on your Fedora system.
|
||||
|
||||
Next, make sure your user is in the wheel group. This special group allows you to run system administration commands. If you created your user as an administrator, such as during installation, you’ll have this group membership. Run the following command:
|
||||
|
||||
```
|
||||
id | grep wheel
|
||||
```
|
||||
|
||||
If you see output, your user is in the group, and you can move on to the next section. If not, run the following command. You’ll need to provide the password for the root account. Substitute your user name for the text <username>:
|
||||
|
||||
```
|
||||
su -c 'usermod -a -G wheel <username>'
|
||||
```
|
||||
|
||||
Then you will need to logout, and log back in, to inherit the group membership properly.
|
||||
|
||||
Now it’s time to create your first Vagrant box, which you’ll then configure using Ansible.
|
||||
|
||||
### Setting up the Vagrant box
|
||||
|
||||
Before you use Ansible to provision a box, you must create the box. To start, create a new directory which will store files related to the Vagrant box. To create this directory and make it the current working directory, issue the following command:
|
||||
|
||||
```
|
||||
mkdir -p ~/lampbox && cd ~/lampbox
|
||||
```
|
||||
|
||||
Before you create the box, you should understand the goal. This box is a simple example that runs CentOS 7 as its base system, along with the Apache web server, MariaDB (the popular open source database server from the original developers of MySQL) and PHP.
|
||||
|
||||
To initialize the Vagrant box, use the vagrant init command:
|
||||
|
||||
```
|
||||
vagrant init centos/7
|
||||
```
|
||||
|
||||
This command initializes the Vagrant box and creates a file named Vagrantfile, with some pre-configured variables. Open this file so you can modify it. The following line lists the base box used by this configuration.
|
||||
|
||||
```
|
||||
config.vm.box = "centos/7"
|
||||
```
|
||||
|
||||
Now setup port forwarding, so after you finish setup and the Vagrant box is running, you can test the server. To setup port forwarding, add the following line just before the end statement in Vagrantfile:
|
||||
|
||||
```
|
||||
config.vm.network "forwarded_port", guest: 80, host: 8080
|
||||
```
|
||||
|
||||
This option maps port 80 of the Vagrant Box to port 8080 of the host machine.
|
||||
|
||||
The next step is to set Ansible as our provisioning provider for the Vagrant Box. Add the following lines before the end statement in your Vagrantfile to set Ansible as the provisioning provider:
|
||||
|
||||
```
|
||||
config.vm.provision :ansible do |ansible|
|
||||
ansible.playbook = "lamp.yml"
|
||||
end
|
||||
```
|
||||
|
||||
(You must add all three lines before the final end statement.) Notice the statement ansible.playbook = “lamp.yml”. This statement defines the name of the playbook used to provision the box.
|
||||
|
||||
### Creating the Ansible playbook
|
||||
|
||||
In Ansible, playbooks describe a policy to be enforced on your remote nodes. Put another way, playbooks manage configurations and deployments on remote nodes. Technically speaking, a playbook is a YAML file in which you write tasks to perform on remote nodes. In this tutorial, you’ll create a playbook named lamp.yml to provision the box.
|
||||
|
||||
To make the playbook, create a file named lamp.yml in the same directory where your Vagrantfile is located and add the following lines to it:
|
||||
|
||||
```
|
||||
---
|
||||
- hosts: all
|
||||
become: yes
|
||||
become_user: root
|
||||
tasks:
|
||||
- name: Install Apache
|
||||
yum: name=httpd state=latest
|
||||
- name: Install MariaDB
|
||||
yum: name=mariadb-server state=latest
|
||||
- name: Install PHP5
|
||||
yum: name=php state=latest
|
||||
- name: Start the Apache server
|
||||
service: name=httpd state=started
|
||||
- name: Install firewalld
|
||||
yum: name=firewalld state=latest
|
||||
- name: Start firewalld
|
||||
service: name=firewalld state=started
|
||||
- name: Open firewall
|
||||
command: firewall-cmd --add-service=http --permanent
|
||||
```
|
||||
|
||||
An explanation of each line of lamp.yml follows.
|
||||
|
||||
- hosts: all specifies the playbook should run over every host defined in the Ansible configuration. Since no hosts are configured hosts yet, the playbook will run on localhost.
|
||||
- sudo: true states the tasks should be performed with root privileges.
|
||||
- tasks: specifies the tasks to perform when the playbook runs. Under the tasks section:
|
||||
- - name: … provides a descriptive name to the task
|
||||
- - yum: … specifies the task should be executed by the yum module. The options name and state are key=value pairs for use by the yum module.
|
||||
|
||||
When this playbook executes, it installs the latest versions of the Apache (httpd) web server, MariaDB, and PHP. Then it installs and starts firewalld, and opens a port for the Apache server. You’re now done writing the playbook for the box. Now it’s time to provision it.
|
||||
|
||||
### Provisioning the box
|
||||
|
||||
A few final steps remain before using the Vagrant Box provisioned using Ansible. To run this provisioning, execute the following command:
|
||||
|
||||
```
|
||||
vagrant up --provider libvirt
|
||||
```
|
||||
|
||||
The above command starts the Vagrant box, downloads the base box image to the host system if not already present, and then runs the playbook lamp.yml to provision.
|
||||
|
||||
If everything works fine, the output looks somewhat similar to this example:
|
||||
|
||||
|
||||
|
||||
This output shows that the box has been provisioned. Now check whether the server is accessible. To confirm, open your web browser on the host machine and point it to the address http://localhost:8080. Remember, port 8080 of the local host is forwarded to port 80 of the Vagrant box. You should be greeted with the Apache welcome page like the one shown below:
|
||||
|
||||
|
||||
|
||||
To make changes to your Vagrant box, first edit the Ansible playbook lamp.yml. You can find plentiful documentation on Ansible at [its official website][4]. Then run the following command to re-provision the box:
|
||||
|
||||
```
|
||||
vagrant provision
|
||||
```
|
||||
|
||||
### Conclusion
|
||||
|
||||
You’ve now seen how to use Ansible to provision Vagrant boxes. This was a basic example, but you can use these tools for many other use cases. For example, you can deploy complete applications along with up-to-date version of required tools. Be creative as you use Ansible to provision your remote nodes or containers.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/using-ansible-provision-vagrant-boxes/
|
||||
|
||||
作者：[Saurabh Badhwar][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: http://h4xr.id.fedoraproject.org/
|
||||
[1]: https://ansible.com/
|
||||
[2]: https://www.vagrantup.com/
|
||||
[3]: https://centos.org/
|
||||
[4]: http://docs.ansible.com/ansible/index.html
|
||||
@ -0,0 +1,58 @@
|
||||
ARCH LINUX MAY SOON BE AVAILABLE ON WINDOWS SUBSYSTEM FOR LINUX
|
||||
====
|
||||
|
||||
[](https://itsfoss.com/wp-content/uploads/2016/10/Arch-Linux-on-windows-subsystem.jpg)
|
||||
|
||||
Ubuntu’s makers [Canonical](http://www.canonical.com/) had worked with Microsoft to bring you the much debated [Bash on Windows](https://itsfoss.com/bash-on-windows/). Although the same has had mixed reviews, many hardcore Linux users questioned its usability and some even considered [Bash on Windows a security risk](https://itsfoss.com/linux-bash-windows-security/).
|
||||
|
||||
Unix’s Bash shell was ported to Windows using a new feature called the “Windows Subsystem for Linux” or the WSL. We already saw how you can [install Bash on Windows](https://itsfoss.com/install-bash-on-windows/) easily.
|
||||
|
||||
The Bash on Windows from Canonical and Microsoft is simply the command line version of Ubuntu, not the regular graphical user interface.
|
||||
|
||||
Well, the good thing about Linux enthusiasts is that give them some time and they’ll do things on Windows Subsystem for Linux for which even the original developers will react with, “Wait, we can do that?”.
|
||||
|
||||
That’s precisely what is happening out there.
|
||||
|
||||
|
||||
|
||||
Yes. IT IS Ubuntu’s Unity shell running on Windows! Pablo Gonzalez, a programmer who goes by the name [Guerra24](https://github.com/Guerra24?tab=overview&from=2016-08-01&to=2016-08-31&utf8=%E2%9C%93) on GitHub has put together this beauty. With this, he has shown that what we can do with the Windows Subsystem for Linux is much more than what it previously was conceived for.
|
||||
|
||||
Now if Ubuntu Unity can be put on Windows subsystem, why not some other Linux distribution?
|
||||
|
||||
### ARCH LINUX FOR BASH ON WINDOWS
|
||||
|
||||
Full fledged distros running natively on WSL. Well, sooner or later it was bound to happen. I’m happier it’s [Arch Linux](https://www.archlinux.org/) though ([Antergos](https://itsfoss.com/tag/antergos/) Lover here).
|
||||
|
||||
|
||||
|
||||
Hold on, hold on there. The project is still in beta. It is being developed by “mintxomat” on GitHub and is currently is on version 0.6\. The first stable version will be released in late December this year.
|
||||
|
||||
Well, what’s the distinguishing point this project brings to the table?
|
||||
|
||||
You might already know that the Windows Subsystem for Linux is available on Windows 10 exclusively. But Arch Linux on Windows Subsystem for Linux (AWSL) has been successfully tested on windows7, Windows 8, Windows 8.1, Windows Server 2012(R2) and Windows 10 of course.
|
||||
|
||||
Whoa, how did they do it?
|
||||
|
||||
The developer says that AWSL protocol achieves this kind of portability by abstracting different frameworks available on different versions of Windows. So it’s the next level when AWSL finally hits 1.0\. And as we discussed the portability stuff already, this project will be the first to bring Bash on all versions of Windows.
|
||||
|
||||
This project is ambitious and promising. If You can’t wait till December then go ahead and give it a try. Just remember it’s a developers preview which is unstable at the moment. But hey, when’s that stopped us?
|
||||
|
||||
You can check out the project on GitHub:
|
||||
|
||||
[Arch on Windows Subsystem](https://github.com/turbo/alwsl)
|
||||
|
||||
[](https://itsfoss.com/10-funny-jokes-pictures-windows-mac-linux/)
|
||||
|
||||
Do share the article and let people know Arch Linux is going to land on Windows soon. Also, let us know which dbistro you want to see on WSL next. Cheers.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/arch-linux-windows-subsystem/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ItsFoss+%28Its+FOSS%21+An+Open+Source+Blog%29
|
||||
|
||||
作者：[Aquil Roshan][a]
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
@ -0,0 +1,87 @@
|
||||
Terminator 一款一个窗口包含多个终端的 Linux 终端仿真器
|
||||
=============================================================================
|
||||
|
||||
|
||||
|
||||
为了通过命令行和系统互动，每一款 Linux 发行版都有一款默认的终端仿真器。但是，默认的终端应用可能不适合你。为了加快你工作的速度，有好多款终端应用提供给你更多的功能来同时执行更多的任务。这些有用的终端仿真器包括 Terminator，一款 Linux 系统下支持多窗口的免费的终端仿真器。
|
||||
|
||||
|
||||
### 什么是 Linux 终端仿真器
|
||||
|
||||
Linux 终端仿真器是一个让你和 shell 交互的程序。所有的 Linux 发行版都会自带一款 Linux 终端应用让你向 shell 传递命令。
|
||||
|
||||
### Terminator，一款免费的 Linux 终端应用
|
||||
|
||||
Terminator 是一款 Linux 终端模拟器，提供了你的默认的终端应用不支持的多个特性。它提供了在一个窗口创建多个终端的功能，加快你的工作速度。除了多窗口外，它也允许你修改其他特性，例如字体、字体颜色、背景色等等。让我们看看我们如何安装它，并且如何在不同的 Linux 发行版下使用 Terminator。
|
||||
|
||||
### 如何在 Linux 下安装Terminator？
|
||||
|
||||
#### 在基于 Ubuntu 的发行版上安装 Terminator
|
||||
|
||||
Terminator 在默认的 Ubuntu 仓库就可以使用。所以你不需要添加额外的 PPA。只需要使用 APT 或者 软件应用在 Ubuntu 下直接安装。
|
||||
|
||||
```
|
||||
sudo apt-get install terminator
|
||||
```
|
||||
|
||||
假如你的默认的仓库中 Terminator 不可使用，只需要使用源码编译 Terminator 即可。
|
||||
|
||||
[下载源码][1]
|
||||
|
||||
下载 Terminator 源码并且解压到你的桌面。现在打开你的默认的终端然后 cd 到解压的目录。
|
||||
|
||||
现在就可以使用下面的命令来安装 Terminator 了 -
|
||||
|
||||
```
|
||||
sudo ./setup.py install
|
||||
```
|
||||
|
||||
#### 在 Fedora 及衍生的操作系统上安装 Terminator
|
||||
|
||||
```
|
||||
dnf install terminator
|
||||
```
|
||||
|
||||
#### 在 OpenSuse 上安装 Terminator
|
||||
|
||||
[在 OPENSUSE 上安装][2]
|
||||
|
||||
### 如何在一个窗口使用多个终端？
|
||||
|
||||
安装好 Terminator 之后，你可以简单的在一个窗口打开多个终端。只需要右键并选择。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
只要你愿意，你可以创建尽可能多的终端，如果你能管理它们的话。
|
||||
|
||||
|
||||
|
||||
### 定制终端
|
||||
|
||||
右键点击终端，并单击属性。现在你可以定制字体、字体颜色、标题颜色和背景，还有终端字体颜色和背景。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 结论：什么是你最喜欢的终端模拟器
|
||||
|
||||
Terminator 是一款高级的终端模拟器，它让你自定义界面。如果你还没有从你默认的终端模拟器中切换过来的话，你可以尝试一下它。我知道你将会喜欢上它。如果你在使用其他的免费的终端模拟器的话，请让我们知道你最喜欢的那一款。而且不要忘了和你的朋友分享这篇文章。或许你的朋友正在寻找类似的东西。
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/mandatory-access-control-with-selinux-or-apparmor-linux/
|
||||
|
||||
作者：[author][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: http://www.linuxandubuntu.com/home/terminator-a-linux-terminal-emulator-with-multiple-terminals-in-one-window
|
||||
[1]: https://launchpad.net/terminator/+download
|
||||
[2]: http://software.opensuse.org/download.html?project=home%3AKorbi123&package=terminator
|
||||
@ -0,0 +1,96 @@
|
||||
监控微服务的5条原则
|
||||
====
|
||||
|
||||
|
||||
|
||||
我们对微服务的需求可以归纳为一个词：速度，提供更多更可靠更快捷的功能的需求，彻底改变了软件开发模式，毫无疑问，这同样改变了软件管理和系统监控的方式。这里，我们着重于有效的监控生产过程中的微服务，我们将为这一新的软件开发模式制定5条原则来调整你的监控方法。
|
||||
|
||||
监控是微服务控制系统的关键部分，你的软件越复杂，那么你就越难了解其性能并解决问题。鉴于微服务给软件部署带来的巨大改变，监控系统同样需要进行彻底的改造。文章接下来介绍监控微服务的5条原则，如下：
|
||||
|
||||
1. 监控容器和里面的东西
|
||||
2. 在服务性能上做监控，而不是容器
|
||||
3. 监控弹性和多变的服务
|
||||
4. 监控开发接口
|
||||
5. 将您的监控映射到您的组织结构
|
||||
|
||||
利用这5条原则，你可以建立更有效的对微服务的监控。这些原则，可以让你定位微服务的技术变化和组织变化。
|
||||
|
||||
### 微服务监控的原则
|
||||
|
||||
#### 1.监控容器和里面的东西
|
||||
|
||||
容器是微服务重要的积木，容器的速度、可移植性和隔离特性让开发者很方便的建立微服务的模型。容器的好处已经写的够多了，在这里我们不再重复。
|
||||
|
||||
容器对于其他的系统来说就像是黑盒子，它的高度的可移植性，对于开发来说简直大有裨益，从开发到生产，甚至从一台笔记本开发直到云端。但是运行起来后，监控和解决服务问题，这个黑盒子让常规的方法失效了，我们会想：容器里到底在运行着什么？这些程序和代码是怎么运行的？它有什么重要的输出指标吗？在开发者的视角，你需要对容器有更深的了解而不是知道一些容器的存在。
|
||||
|
||||
|
||||
|
||||
非容器环境的典型特征，一个代理程序运行在一台主机或者虚机的用户空间，但是容器里不一样。容器的有点是小，讲各种进程分离开来，尽可能的减少依赖关系。
|
||||
|
||||
在规模上看，成千上万的监测代理，对即使是一个中等大小的部署都是一个昂贵的资源浪费和业务流程的噩梦。对于容器有两个潜在的解决方案：1）要求你的开发人员直接提交他们的代码，或者2）利用一个通用的内核级的检测方法来查看主机上的所有应用程序和容器活动。我们不会在这里深入，但每一种方法都有优点和缺点。
|
||||
|
||||
#### 2. 利用业务流程系统提醒服务性能
|
||||
|
||||
理解容器中数据的运行方式并不容易，一个容器的度量值比组成函数或服务的所有容器的聚合信息都要低得多。
|
||||
|
||||
这特别适用于应用程序级别的信息，就像哪个请求拥有最短响应时间或者哪个URLs有最多的错误，同样也适用于基础设施水平监测，比如哪个服务的容器使用CPU资源超过了事先分配的资源数。
|
||||
|
||||
越来越多的软件部署需要一个业务流程系统，将逻辑化的应用程序转化到一个物理的容器中。
|
||||
常见的转化系统包括Kubernetes、Mesosphere DC/OS和Docker Swarm。团队用一个业务流程系统来定义微服务和理解部署每个服务的当前状态。容器是短暂的，只有满足你的服务需求才会存在。
|
||||
|
||||
DevOps团队应该尽可能将重点放到如何更好的监控服务的运行特点上，如果应用受到了影响，这些告警点要放在第一道评估线上。但是能观察到这些告警点也并不容易，除非你的监控系统是容器本地的。
|
||||
|
||||
容器原生解决方案利用业务流程元数据来动态聚合容器和应用程序数据，并计算每个服务基础上的监控度量。根据您的业务流程工具，您可能有不同层次的层次结构想检测。比如，在Kubernetes里，你通常有Namespace、ReplicaSets、Pods和一些其他容器。聚集在这些不同的层有助于故障排除，这与构成服务的容器的物理部署无关。
|
||||
|
||||
|
||||
|
||||
#### 3. 监控弹性和多变的服务
|
||||
|
||||
弹性服务不是一个新概念，但是它在本地容器中的变化速度比在虚拟环境中快的多。迅速的变化会严重影响检测系统的正常运行。
|
||||
|
||||
经常监测系统所需的手动调整指标和单独部署的软件，这种调整可以是具体的，如定义要捕获的单个指标，或收集应用程序在一个特定的容器中操作的配置数据。小规模上我们可以接受，但是数以万计规模的容器就不行了。微服务的集中监控必须能够自由的监控弹性服务的增长和缩减，而且无人工干预。
|
||||
|
||||
比如，开发团队必须手动定义容器包含那个服务做监控使用，他们毫无疑问会把球抛给Kubernetes或者Mesos定期的创建新的容器。同样，如果开发团队需要配置一个自定义的状态点从新代码的产生到付诸生产，那么基础镜像从容器中注册会给开发者带来更多的挑战。
|
||||
|
||||
在生产中，建立一个复杂的跨越多个数据中心或多个云部署的监控，会使你的服务跨越你的死人数据中心，具体的应用，比如亚马逊的AWS CloudWatch。通过动态的本地容器环境，这个实时监控系统，会监控不同区域的数据中心。
|
||||
|
||||
#### 4.监控开发接口
|
||||
|
||||
在微服务环境中，API接口是通用的。它们是一个服务的必备组件，实际上，API的响应和一致性是服务的内部语言，虽然暂时还没人定义它们。
|
||||
|
||||
因此，API接口的监控也是必需的。API监控可以有不同的形式，但是它绝对不是简单的上下检查。例如，了解最常使用的点作为时间函数是有价值的。这使得团队可以看到，服务使用的变化，无论是由于设计变更或用户的改变。
|
||||
|
||||
你也可以记录服务最缓慢的点，这些可以揭示重大的问题，至少，指向需要在系统中做优化的区域。
|
||||
|
||||
最终，跟踪系统服务响应会成为一个很重要的能力，它会帮助开发者了解最终用户体验，同时将信息分成基础设施和应用程序环境两大部分。
|
||||
|
||||
#### 5. 将您的监控映射到您的组织结构
|
||||
|
||||
这篇文章着重在微服务和监控上，像其他科技文章一样，这是因为很多人都关注软件层面。
|
||||
|
||||
对于那些熟悉康威定律的人来说，系统的设计是基于开发团队的组织结构。创造更快，更敏捷的软件的迫力，推动团队思考重新调整他们的组织结构和管理它的规则。
|
||||
|
||||
|
||||
|
||||
如果他们想从新的软件架构比如微服务上获益，那么他们需要更小的更松散更耦合的团队，可以选择自己的方向只要能够满足整个需求即可。在一个团队中，对于什么开发语言的使用，bug的提交甚至工作职责都会有更大的控制能力。
|
||||
|
||||
开发团队可以启用一个监控平台：让每一个微服务团队可以定位自己的警报，指标，和控制面板，同时也要给全局系统的操作一个图表。
|
||||
|
||||
### 总结
|
||||
|
||||
快捷让微服务流行起来。开发组织要想为客户提供更快的更多的功能，然后微服务技术就来了，架构转向微服务并且容器的流行让快捷开发成为可能，所有相关的进程理所当然的搭上了这辆火车。
|
||||
|
||||
最后，基本的监控原则需要适应加入到微服务的技术和结构。越早认识到这种转变的开发团队，能更早更容易的适应微服务这一新的架构。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://linoxide.com/firewall/pfsense-setup-basic-configuration/
|
||||
|
||||
作者：[Apurva Dave][a] [Loris Degioanni][b]
|
||||
译者：[jiajia9linuxer](https://github.com/jiajia9linuxer)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: http://thenewstack.io/author/apurvadave/
|
||||
[b]: http://thenewstack.io/author/lorisdegioanni/
|
||||
@ -0,0 +1,159 @@
|
||||
用Ansible来配置Vagrant Boxes
|
||||
====
|
||||
|
||||
|
||||
|
||||
Ansible 是一款系统管理员进行自动化运维的强大工具。Ansible 让配置、交付、管理各种容器，软件部署变得非常简单[1]。基于轻量级模块的架构非常适合系统管理，一个优点就是如果某个节点没有被 Ansible 管理的话，它的资源是没有被使用的。
|
||||
|
||||
这篇文章介绍用 Ansible 来配置 Vagrant boxes，它是一个配置好的基础虚拟机映像，包含在开发环境中需要用到的工具。你可以用它来部署开发环境，然后和其他成员协同工作。用 Ansible，你可以用你的开发包自动化配置 Vagrant boxes。
|
||||
|
||||
我们用 Fedora 24 做主机，用 CentOS 7 来作 Vagrant box
|
||||
|
||||
### 设置工作环境
|
||||
|
||||
在用 Ansible 配置 Vagrant boxes 时，你需要做几件准备的事情。首先在主机上安装 Ansible 和 Vagrant，在主机上运行下面的命令来安装：
|
||||
|
||||
```
|
||||
sudo dnf install ansible vagrant vagrant-libvirt
|
||||
```
|
||||
|
||||
上面的命令将 Ansible 和 Vagrant 在你的主机上，也包括 Vagrant 的自动部署工具。Vagrant 不能自己管理虚拟主机，需要第三方工具比如：libirt，VirtualBox，VMWare等等。工具直接在你的 Fedora 系统上运行。
|
||||
|
||||
接着确认你的账户在正确的用户组 wheel 当中，确保你可以运行系统管理员命令。如果你的账号在安装过程中就创建为管理员，那么你就肯定在这个用户组里。运行下面的命令：
|
||||
|
||||
```
|
||||
id | grep wheel
|
||||
```
|
||||
|
||||
如果你能看到输出，那么你的账户就在这个组里，可以进行下一步。如果没有的话，你需要运行下面的命令，这一步需要你提供 root 账户的密码，在<username>里加上你的用户名：
|
||||
|
||||
```
|
||||
su -c 'usermod -a -G wheel <username>'
|
||||
```
|
||||
|
||||
然后，你需要注销然后重新登录，确保在用户组里。
|
||||
|
||||
现在要建立你的第一个 Vagrant box 了，你需要用 Ansible 来配置它。
|
||||
|
||||
### 设置 Vagrant box
|
||||
|
||||
配置一个镜像 box 之前，你需要先创建它。创建一个目录，存放 Vagrant box 相关的文件，并且将它设置为工作目录，用下面这条命令：
|
||||
|
||||
```
|
||||
mkdir -p ~/lampbox && cd ~/lampbox
|
||||
```
|
||||
|
||||
在创建镜像 box 之前，你需要搞清楚目的，这个镜像 box 是一个运行 CentOS 7 基础系统的模板包括 Apache 的 web 服务，MariaDB（MySQL 原始开发者创建的一个流行的开源数据库）数据库和 PHP 服务。
|
||||
|
||||
初始化 Vagrant box，用 vagrant 开发工具初始化命令：
|
||||
|
||||
```
|
||||
vagrant init centos/7
|
||||
```
|
||||
|
||||
这个命令初始化 Vagrant box 创建一些 Vagrantfile 名字的文件，也包含一些预先配置的文件。你可以打开和编辑它们，下面的命令显示基本的镜像box和配置。
|
||||
|
||||
```
|
||||
config.vm.box = "centos/7"
|
||||
```
|
||||
|
||||
设置端口转发，这样在你设置玩 Vagrant box 之后可以测试它。用下面的命令实现：
|
||||
|
||||
```
|
||||
config.vm.network "forwarded_port", guest: 80, host: 8080
|
||||
```
|
||||
|
||||
这个命令将 Vagrant Box 的 80 端口映射为主机的 8080 端口。
|
||||
|
||||
下一步是设置 Ansible 作为配置 Vagrant Box 的工具，下面的命令将 Ansible 作为配置工具在 end 之前加入到 Vagrantfile 中：
|
||||
|
||||
```
|
||||
config.vm.provision :ansible do |ansible|
|
||||
ansible.playbook = "lamp.yml"
|
||||
end
|
||||
```
|
||||
|
||||
（必须将这三行在最后的语句之前加入）ansible.playbook = "lamp.yml"这一句定义了配置镜像box的手册的名字。
|
||||
|
||||
### 创建Ansible详细手册
|
||||
|
||||
Ansible 的手册描述的是执行在你的远端节点的策略，换句话说，它管理远端节点的配置和部署。详细的说，手册是一个 Yaml 文件，在里面你写入在远端节点上将要执行的任务。所以，你需要创建一个名为 lamp.yml 的手册来配置镜像 box。
|
||||
|
||||
在 Vagrantfile 的目录里创建一个 lamp.yml 文件，将下面的内容粘贴到文件当中：
|
||||
|
||||
```
|
||||
---
|
||||
- hosts: all
|
||||
become: yes
|
||||
become_user: root
|
||||
tasks:
|
||||
- name: Install Apache
|
||||
yum: name=httpd state=latest
|
||||
- name: Install MariaDB
|
||||
yum: name=mariadb-server state=latest
|
||||
- name: Install PHP5
|
||||
yum: name=php state=latest
|
||||
- name: Start the Apache server
|
||||
service: name=httpd state=started
|
||||
- name: Install firewalld
|
||||
yum: name=firewalld state=latest
|
||||
- name: Start firewalld
|
||||
service: name=firewalld state=started
|
||||
- name: Open firewall
|
||||
command: firewall-cmd --add-service=http --permanent
|
||||
```
|
||||
|
||||
每一行代表的意思：
|
||||
|
||||
- hosts: 定义 Ansible 配置文件需要在所有的主机上运行，因为还没定义主机，暂时只在本地运行。
|
||||
- sudo: 需要用 root 权限运行的任务
|
||||
- tasks: 确定的任务
|
||||
- - name: 描述任务的名字
|
||||
- - yum: 描述任务需要调用 yum 模块，需要 key=value 成对被 yum 模块调用。
|
||||
|
||||
当手册运行时，它会安装最新的 Apache 的 web 服务，MariaDB 和 PHP。当安装完毕开始工作，会给 Apache 打开一个端口。你可以给镜像 box 写手册，并且可以配置它了。
|
||||
|
||||
### 配置镜像 box
|
||||
|
||||
用 Ansible 配置 Vagrant Box 只需要以下几部了：
|
||||
|
||||
```
|
||||
vagrant up --provider libvirt
|
||||
```
|
||||
|
||||
上面的命令运行 Vagrant box，将基本的镜像 box 下载到主机当中，然后运行 lamp.yml 手册来进行配置。
|
||||
|
||||
如果一切正常，输出应该和下面的例子类似：
|
||||
|
||||
|
||||
|
||||
这个输出显示镜像 box 已经被配置好了，现在检查服务是否可用，打开浏览器，输入 http://localhost:8080，记住主机的 8080 端口是 Vagrant box 映射过来的 80 端口。你应该可以看到如下的 Apache 的欢迎界面。
|
||||
|
||||
|
||||
|
||||
改变 Vagrantbox，你可以修改 lamp.yml 手册，你能从 Ansible 的官网上找到很多文章。然后运行下面的命令：
|
||||
|
||||
```
|
||||
vagrant provision
|
||||
```
|
||||
|
||||
### 总结
|
||||
|
||||
现在我们知道怎么用 Ansible 来配置 Vagrant boxes 了。这只是一个基本的例子，但是你可以用这些工具来实现不同的例子。比如你可以部署最新的工具，现在你可以用 Ansible 来配置你自己的远端服务器和容器了。
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/using-ansible-provision-vagrant-boxes/
|
||||
|
||||
作者：[Saurabh Badhwar][a]
|
||||
译者：[jiajia9linuxer](https://github.com/jiajia9linuxer)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: http://h4xr.id.fedoraproject.org/
|
||||
[1]: https://ansible.com/
|
||||
[2]: https://www.vagrantup.com/
|
||||
[3]: https://centos.org/
|
||||
[4]: http://docs.ansible.com/ansible/index.html
|
||||
Loading…
Reference in New Issue
Block a user