也许你会惊奇在新安装的 Fedroa 22中没有找到 yum 包，也不明白为何在调用 /usr/bin/yum 或使用各种 Yum 插件时会得到警告。嗯，你看到的没错，Yum 已经去了~。直白的说， DNF 现在是 Fedora 上默认是包管理器了。

DNF 由 Yum 中分支出来，采用了基于 SAT 的依赖解决算法，目标是在 Fedora 22中取代 Yum。随着 DNF 1.0 的发布，已经到了取而代之的时候了。Yum 无法适应倡导“默认即 Python 3”理念的 Fedora ，而 DNF 则可以同时支持 Python 2 和 Python 3。 DNF 按照相同的语义逻辑保留了命令行接口的一致。幸运的是，DNF 的 Python API 是完全不同于 Yum 的。这两个项目之间的所有已知的不兼容都已经记录在案了。在 Fedora Core 22 中只有 DNF，官方不会提供 Yum 了。当然，如果你愿意，可以自己下载它。这个包仍然可以如同以往一样调用， Python API 也没变化，只是 yum 程序的名称被改名为 yum-deprecated 了，而且从命令行调用 yum 会被重定向到 DNF。这样，你就可以在系统上同时维持 Yum 和 DNF 了。

启动 DNF 项目的原因是由于 Yum 的三大问题：API 缺乏文档、有问题的依赖解决算法，及无法重构内部函数。这里提到的最后一个问题，其实和文档的缺乏有关。Yum 插件使用的各种方法来源于 Yum 的代码，一旦改变有可能造成 Yum 的突然崩溃！DNF 致力于解决这些 Yum 的问题，从一开始，所有对外的 API 的要做好完备的文档。在绝大多数新提交中都包含了测试单元。不允许各种奇怪的、乱七八糟的补丁。该项目是通过敏捷开发进行的：对用户会有较大影响的需求会得到尽快的实现。

现在，DNF 团队正在移植各种流行的 Yum 插件到 DNF 上，并改进其用户体验。为了更加方便切换到 DNF，我们开发了一个 DNF 移植插件，来将 Yum 中已经安装的包、分组和事务数据导入到新的 Fedora 包管理器中。赶快转移到 DNF 吧，希望你喜欢！

Jan Silhan, by DNF team

对任何规模的业务来说，网络监控工具都是一个重要的功能。网络监控的目标可能千差万别。比如，监控活动的目标可以是保证长期的网络服务、安全保护、对性能进行排查、网络使用统计等。由于它的目标不同，网络监控器使用很多不同的方式来完成任务。比如对包层面的嗅探，对数据流层面的统计数据，向网络中注入探测的流量，分析服务器日志等。

尽管有许多专用的网络监控系统可以365天24小时监控，但您依旧可以在特定的情况下使用命令行式的网络监控器，某些命令行式的网络监控器在某方面很有用。如果您是系统管理员，那您就应该有亲身使用一些知名的命令行式网络监控器的经历。这里有一份Linux上流行且实用的网络监控器列表。

包层面的嗅探器

在这个类别下，监控工具在链路上捕捉独立的包，分析它们的内容，展示解码后的内容或者包层面的统计数据。这些工具在最底层对网络进行监控、管理，同样的也能进行最细粒度的监控，其代价是影响网络I/O和分析的过程。

1. dhcpdump：一个命令行式的DHCP流量嗅探工具，捕捉DHCP的请求/回复流量，并以用户友好的方式显示解码的DHCP协议消息。这是一款排查DHCP相关故障的实用工具。
2. dsniff：一个基于命令行的嗅探、伪造和劫持的工具合集，被设计用于网络审查和渗透测试。它可以嗅探多种信息，比如密码、NSF流量（LCTT 译注：此处疑为 NFS 流量）、email消息、网络地址等。
3. httpry：一个HTTP报文嗅探器，用于捕获、解码HTTP请求和回复报文，并以用户友好的方式显示这些信息。（LCTT 译注：延伸阅读。 ）
4. IPTraf：基于命令行的网络统计数据查看器。它实时显示包层面、连接层面、接口层面、协议层面的报文/字节数。抓包过程由协议过滤器控制，且操作过程全部是菜单驱动的。（LCTT 译注：延伸阅读。）

5. mysql-sniffer：一个用于抓取、解码MySQL请求相关的数据包的工具。它以可读的方式显示最频繁或全部的请求。
6. ngrep：在网络报文中执行grep。它能实时抓取报文，并用正则表达式或十六进制表达式的方式匹配（过滤）报文。它是一个可以对异常流量进行检测、存储或者对实时流中特定模式报文进行抓取的实用工具。
7. p0f：一个被动的基于包嗅探的指纹采集工具，可以可靠地识别操作系统、NAT或者代理设置、网络链路类型以及许多其它与活动的TCP连接相关的属性。
8. pktstat：一个命令行式的工具，通过实时分析报文，显示连接带宽使用情况以及相关的协议（例如，HTTP GET/POST、FTP、X11）等描述信息。

9. Snort：一个入侵检测和预防工具，通过规则驱动的协议分析和内容匹配，来检测/预防活跃流量中各种各样的后门、僵尸网络、网络钓鱼、间谍软件攻击。
10. tcpdump：一个命令行的嗅探工具，可以基于过滤表达式抓取网络中的报文，分析报文，并且在包层面输出报文内容以便于包层面的分析。他在许多网络相关的错误排查、网络程序debug、或安全监测方面应用广泛。
11. tshark：一个与Wireshark窗口程序一起使用的命令行式的嗅探工具。它能捕捉、解码网络上的实时报文，并能以用户友好的方式显示其内容。

流/进程/接口层面的监控

在这个分类中，网络监控器通过把流量按照流、相关进程或接口分类，收集每个流、每个进程、每个接口的统计数据。其信息的来源可以是libpcap抓包库或者sysfs内核虚拟文件系统。这些工具的监控成本很低，但是缺乏包层面的检视能力。

1. bmon：一个基于命令行的带宽监测工具，可以显示各种接口相关的信息，不但包括接收/发送的总量/平均值统计数据，而且拥有历史带宽使用视图。

2. iftop：一个带宽使用监测工具，可以实时显示某个网络连接的带宽使用情况。它对所有带宽使用情况排序并通过ncurses的接口来进行可视化。他可以方便的监控哪个连接消耗了最多的带宽。（LCTT 译注：延伸阅读。）
3. nethogs：一个基于ncurses显示的进程监控工具，提供进程相关的实时的上行/下行带宽使用信息。它对检测占用大量带宽的进程很有用。（LCTT 译注：延伸阅读。）
4. netstat：一个显示许多TCP/UDP的网络堆栈的统计信息的工具。诸如打开的TCP/UDP连接书、网络接口发送/接收、路由表、协议/套接字的统计信息和属性。当您诊断与网络堆栈相关的性能、资源使用时它很有用。
5. speedometer：一个可视化某个接口发送/接收的带宽使用的历史趋势，并且基于ncurses的条状图进行显示的终端工具。

6. sysdig：一个可以通过统一的界面对各个Linux子系统进行系统级综合性调试的工具。它的网络监控模块可以监控在线或离线、许多进程/主机相关的网络统计数据，例如带宽、连接/请求数等。（LCTT 译注：延伸阅读。）
7. tcptrack：一个TCP连接监控工具，可以显示活动的TCP连接，包括源/目的IP地址/端口、TCP状态、带宽使用等。

8. vnStat：一个存储并显示每个接口的历史接收/发送带宽视图（例如，当前、每日、每月）的流量监控器。作为一个后台守护进程，它收集并存储统计数据，包括接口带宽使用率和传输字节总数。（LCTT 译注：延伸阅读。）

主动网络监控器

不同于前面提到的被动的监听工具，这个类别的工具们在监听时会主动的“注入”探测内容到网络中，并且会收集相应的反应。监听目标包括路由路径、可供使用的带宽、丢包率、延时、抖动（jitter）、系统设置或者缺陷等。

1. dnsyo：一个DNS检测工具，能够管理跨越多达1500个不同网络的开放解析器的DNS查询。它在您检查DNS传播或排查DNS设置的时候很有用。
2. iperf：一个TCP/UDP带宽测量工具，能够测量两个端点间最大可用带宽。它通过在两个主机间单向或双向的输出TCP/UDP探测流量来测量可用的带宽。它在监测网络容量、调谐网络协议栈参数时很有用。一个叫做netperf的变种拥有更多的功能及更好的统计数据。
3. netcat/socat：通用的网络调试工具，可以对TCP/UDP套接字进行读、写或监听。它通常和其他的程序或脚本结合起来在后端对网络传输或端口进行监听。（LCTT 译注：延伸阅读。）
4. nmap：一个命令行的端口扫描和网络发现工具。它依赖于若干基于TCP/UDP的扫描技术来查找开放的端口、活动的主机或者在本地网络存在的操作系统。它在你审查本地主机漏洞或者建立维护所用的主机映射时很有用。zmap是一个类似的替代品，是一个用于互联网范围的扫描工具。（LCTT 译注：延伸阅读。）
5. ping：一个常用的网络测试工具。通过交换ICMP的echo和reply报文来实现其功能。它在测量路由的RTT、丢包率以及检测远端系统防火墙规则时很有用。ping的变种有更漂亮的界面（例如，noping）、多协议支持（例如，hping）或者并行探测能力（例如，fping）。（LCTT 译注：延伸阅读。）

6. sprobe：一个启发式推断本地主机和任意远端IP地址之间的网络带宽瓶颈的命令行工具。它使用TCP三次握手机制来评估带宽的瓶颈。它在检测大范围网络性能和路由相关的问题时很有用。
7. traceroute：一个能发现从本地到远端主机的第三层路由/转发路径的网络发现工具。它发送限制了TTL的探测报文，收集中间路由的ICMP反馈信息。它在排查低速网络连接或者路由相关的问题时很有用。traceroute的变种有更好的RTT统计功能（例如，mtr）。

应用日志解析器

在这个类别下的网络监测器把特定的服务器应用程序作为目标（例如，web服务器或者数据库服务器）。由服务器程序产生或消耗的网络流量通过它的日志被分析和监测。不像前面提到的网络层的监控器，这个类别的工具能够在应用层面分析和监控网络流量。

1. GoAccess：一个针对Apache和Nginx服务器流量的交互式查看器。基于对获取到的日志的分析，它能展示包括日访问量、最多请求、客户端操作系统、客户端位置、客户端浏览器等在内的多个实时的统计信息，并以滚动方式显示。

2. mtop：一个面向MySQL/MariaDB服务器的命令行监控器，它可以将成本最大的查询和当前数据库服务器负载以可视化的方式显示出来。它在您优化MySQL服务器性能、调谐服务器参数时很有用。

3. ngxtop：一个面向Nginx和Apache服务器的流量监测工具，能够以类似top指令的方式可视化的显示Web服务器的流量。它解析web服务器的查询日志文件并收集某个目的地或请求的流量统计信息。

总结

在这篇文章中，我展示了许多命令行式监测工具，从最底层的包层面的监控器到最高层应用程序层面的网络监控器。了解那个工具的作用是一回事，选择哪个工具使用又是另外一回事。单一的一个工具不能作为您每天使用的通用的解决方案。一个好的系统管理员应该能决定哪个工具更适合当前的环境。希望这个列表对此有所帮助。

欢迎您通过回复来改进这个列表的内容！

via: http://xmodulo.com/useful-command-line-network-monitors-linux.html

作者：Dan Nanni 译者：wwy-hust 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

提问: 我打算在linux上安装autossh，我应该怎么做呢?

autossh 是一款开源工具，可以帮助管理SSH会话、自动重连和停止转发流量。autossh会假定目标主机已经设定无密码SSH登陆，以便autossh可以重连断开的SSH会话而不用用户操作。

只要你建立反向SSH隧道或者挂载基于SSH的远程文件夹，autossh迟早会派上用场。基本上只要需要维持SSH会话，autossh肯定是有用的。

下面有许多linux发行版autossh的安装方法。

Debian 或 Ubuntu 系统

autossh已经加入基于Debian系统的基础库，所以可以很方便的安装。

$ sudo apt-get install autossh 

Fedora 系统

Fedora库同样包含autossh包，使用yum安装。

$ sudo yum install autossh 

CentOS 或 RHEL 系统

CentOS/RHEL 6 或早期版本, 需要开启第三库Repoforge库, 然后才能使用yum安装.

$ sudo yum install autossh 

CentOS/RHEL 7以后，autossh 已经不在Repoforge库中. 你需要从源码编译安装（例子在下面）。

Arch Linux 系统

$ sudo pacman -S autossh 

Debian 或 Ubuntu 系统中从源码编译安装

如果你想要使用最新版本的autossh，你可以自己编译源码安装

$ sudo apt-get install gcc make
$ wget http://www.harding.motd.ca/autossh/autossh-1.4e.tgz
$ tar -xf autossh-1.4e.tgz
$ cd autossh-1.4e
$ ./configure
$ make
$ sudo make install 

CentOS, Fedora 或 RHEL 系统中从源码编译安装

在CentOS/RHEL 7以后，autossh不在是预编译包。所以你不得不从源码编译安装。

$ sudo yum install wget gcc make
$ wget http://www.harding.motd.ca/autossh/autossh-1.4e.tgz
$ tar -xf autossh-1.4e.tgz
$ cd autossh-1.4e
$ ./configure
$ make
$ sudo make install 

via: http://ask.xmodulo.com/install-autossh-linux.html

作者：Dan Nanni 译者：Vic020/VicYu 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

大家好，今天我们要学习一下怎样在github.com提供的仓库中托管开源软件源代码。GitHub是一个基于web的Git仓库托管服务，提供基于 git 的分布式版本控制和源代码管理(SCM)功能，并加入了自身的特点。它给开源项目和私有项目提供了一个互相协作的工作区、代码预览和代码管理功能。不像Git是一个完完全全的命令行工具，GitHub提供了一个基于web的图形化界面和桌面，也整合了手机操作。GitHub同时提供了私有库付费计划和通常用来管理开源软件项目的免费账号。

这是一种快速灵活，基于web的托管服务，它使用方便，管理分布式版本控制系统也是相当容易，任何人都能将他们的软件源代码托管到 github，让全球各地数以百万计的人可以使用它、参与贡献、共享它、进行问题跟踪以及更多的用途。这里有一些简单快速地托管软件源代码的方法。

1. 创建一个新的Github账号

首先，打开你最喜欢的浏览器并访问github，首页页面如下所示。

现在，首页打开之后，请填写一个新的github账号用于注册。

输入注册所需的有效信息之后，你会被转到计划选择的步骤。在这个页面上有5种计划，我们可以根据需要来选择，这里我们要选择免费计划。所以，我们点击选择Free计划并完成注册。如果我们接下去还打算创建一个组织，那我们需要勾选“Help me setup an organization next”。

2. 创建一个新的库

成功注册新账号或登录上Github之后，我们需要创建一个新的库来开始我们的征程。

点击位于顶部靠右账号id旁边的(+)按钮，然后点击“New Repository”。

点击创建一个新的库之后，我们进入了填写所需信息的页面。

填写好信息之后，我们点击绿色的“Create repository”按钮。

这些步骤都做完之后，我们将看到类似于下面这张图的页面。

3. 上传一个已有项目

如果我们想在Github上分享我们的项目，我们自然要把代码推上我们创建的库中。想要这样的话，我们首先要在我们的Linux机器上安装git。如果我在机器上运行的是Ubuntu 14.04 LTS，我需要运行apt工具来安装它。

$ sudo apt-get install git

现在git已经准备就绪，我们要上传代码了。

注意：为了避免错误，不要在初始化的新库中包含README、license或gitignore等文件，你可以在项目推送到Github上之后再添加它们。

在终端上，我们需要切换当前工作目录为你的本地项目的目录，然后将其初始化为Git库。

$ git init

接着我们添加新的本地库里中的文件，作为我们的首次提交内容。

$ git add .

现在我们就提交我们在本地库所添加的文件。

$ git commit -m 'First commit'

在终端上，添加远程库的URL地址，以便我们的本地库推送到远程。

$ git remote add origin 远程库的URL
$ git remote -v

注意：请确保将上述“远程库的URL”替换成了你自己的远程库的URL。

现在，要将我们的本地库的改变推送至GitHub的版本库中，我们需要运行以下命令，并且输入所需的用户名和密码。

$ git push origin master

克隆一个库

如果我们想用一条简单地命令从github上下载代码库至本机上，我们可以用git clone命令，该命令将会从远程库中克隆最新的目录。

$ git clone https://github.com/aruntechgeek/linspeed.git

请把以上这条URL地址更改成你想要克隆的地址。

推送改动

如果我们对我们的代码做了更改并想把它们推送至我们的远程库中，我们应该在该目录下运行以下命令。

$ git add .
$ git commit -m "Updating"
$ git push

结论

啊哈！我们已经成功地将我们的项目源代码托管到Github的库中了。Github是快速灵活的基于web的托管服务，分布式版本控制系统使用起来方便容易。数百万个非常棒的开源项目驻扎在github上。所以，如果你有任何问题、建议或反馈，请在评论中告诉我们。谢谢大家！好好享受吧 :-)

via: http://linoxide.com/usr-mgmt/host-open-source-code-repository-github/

作者：Arun Pyasi 译者：ZTinoZ 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

Linux系统的启动方式有点复杂，而且总是有需要优化的地方。传统的Linux系统启动过程主要由著名的init进程（也被称为SysV init启动系统）处理，而基于init的启动系统被认为有效率不足的问题，systemd是Linux系统机器的另一种启动方式，宣称弥补了以传统Linux SysV init为基础的系统的缺点。在这里我们将着重讨论systemd的特性和争议，但是为了更好地理解它，也会看一下通过传统的以SysV init为基础的系统的Linux启动过程是什么样的。友情提醒一下，systemd仍然处在测试阶段，而未来发布的Linux操作系统也正准备用systemd启动管理程序替代当前的启动过程（LCTT 译注：截止到本文发表，主流的Linux发行版已经有很多采用了 systemd）。

理解Linux启动过程

在我们打开Linux电脑的电源后第一个启动的进程就是init。分配给init进程的PID是1。它是系统其他所有进程的父进程。当一台Linux电脑启动后，处理器会先在系统存储中查找BIOS，之后BIOS会检测系统资源然后找到第一个引导设备，通常为硬盘，然后会查找硬盘的主引导记录（MBR），然后加载到内存中并把控制权交给它，以后的启动过程就由MBR控制。

主引导记录会初始化引导程序（Linux上有两个著名的引导程序，GRUB和LILO，80%的Linux系统在用GRUB引导程序），这个时候GRUB或LILO会加载内核模块。内核会马上查找/sbin下的“init”程序并执行它。从这里开始init成为了Linux系统的父进程。init读取的第一个文件是/etc/inittab，通过它init会确定我们Linux操作系统的运行级别。它会从文件/etc/fstab里查找分区表信息然后做相应的挂载。然后init会启动/etc/init.d里指定的默认启动级别的所有服务/脚本。所有服务在这里通过init一个一个被初始化。在这个过程里，init每次只启动一个服务，所有服务/守护进程都在后台执行并由init来管理。

关机过程差不多是相反的过程，首先init停止所有服务，最后阶段会卸载文件系统。

以上提到的启动过程有一些不足的地方。而用一种更好的方式来替代传统init的需求已经存在很长时间了。也产生了许多替代方案。其中比较著名的有Upstart，Epoch，Muda和Systemd。而Systemd获得最多关注并被认为是目前最佳的方案。

理解Systemd

开发Systemd的主要目的就是减少系统引导时间和计算开销。Systemd（系统管理守护进程），最开始以GNU GPL协议授权开发，现在已转为使用GNU LGPL协议，它是如今讨论最热烈的引导和服务管理程序。如果你的Linux系统配置为使用Systemd引导程序，它取替传统的SysV init，启动过程将交给systemd处理。Systemd的一个核心功能是它同时支持SysV init的后开机启动脚本。

Systemd引入了并行启动的概念，它会为每个需要启动的守护进程建立一个套接字，这些套接字对于使用它们的进程来说是抽象的，这样它们可以允许不同守护进程之间进行交互。Systemd会创建新进程并为每个进程分配一个控制组（cgroup）。处于不同控制组的进程之间可以通过内核来互相通信。systemd处理开机启动进程的方式非常漂亮，和传统基于init的系统比起来优化了太多。让我们看下Systemd的一些核心功能。

• 和init比起来引导过程简化了很多
• Systemd支持并发引导过程从而可以更快启动
• 通过控制组来追踪进程，而不是PID
• 优化了处理引导过程和服务之间依赖的方式
• 支持系统快照和恢复
• 监控已启动的服务；也支持重启已崩溃服务
• 包含了systemd-login模块用于控制用户登录
• 支持加载和卸载组件
• 低内存使用痕迹以及任务调度能力
• 记录事件的Journald模块和记录系统日志的syslogd模块

Systemd同时也清晰地处理了系统关机过程。它在/usr/lib/systemd/目录下有三个脚本，分别叫systemd-halt.service，systemd-poweroff.service，systemd-reboot.service。这几个脚本会在用户选择关机，重启或待机时执行。在接收到关机事件时，systemd首先卸载所有文件系统并停止所有内存交换设备，断开存储设备，之后停止所有剩下的进程。

Systemd结构概览

让我们看一下Linux系统在使用systemd作为引导程序时的开机启动过程的结构性细节。为了简单，我们将在下面按步骤列出来这个过程：

1. 当你打开电源后电脑所做的第一件事情就是BIOS初始化。BIOS会读取引导设备设定，定位并传递系统控制权给MBR（假设硬盘是第一引导设备）。

2. MBR从Grub或LILO引导程序读取相关信息并初始化内核。接下来将由Grub或LILO继续引导系统。如果你在grub配置文件里指定了systemd作为引导管理程序，之后的引导过程将由systemd完成。Systemd使用“target”来处理引导和服务管理过程。这些systemd里的“target”文件被用于分组不同的引导单元以及启动同步进程。

3. systemd执行的第一个目标是default.target。但实际上default.target是指向graphical.target的软链接。Linux里的软链接用起来和Windows下的快捷方式一样。文件Graphical.target的实际位置是/usr/lib/systemd/system/graphical.target。在下面的截图里显示了graphical.target文件的内容。

4. 在这个阶段，会启动multi-user.target而这个target将自己的子单元放在目录“/etc/systemd/system/multi-user.target.wants”里。这个target为多用户支持设定系统环境。非root用户会在这个阶段的引导过程中启用。防火墙相关的服务也会在这个阶段启动。

"multi-user.target"会将控制权交给另一层“basic.target”。

5. "basic.target"单元用于启动普通服务特别是图形管理服务。它通过/etc/systemd/system/basic.target.wants目录来决定哪些服务会被启动，basic.target之后将控制权交给sysinit.target.

6. "sysinit.target"会启动重要的系统服务例如系统挂载，内存交换空间和设备，内核补充选项等等。sysinit.target在启动过程中会传递给local-fs.target。这个target单元的内容如下面截图里所展示。

7. local-fs.target，这个target单元不会启动用户相关的服务，它只处理底层核心服务。这个target会根据/etc/fstab和/etc/inittab来执行相关操作。

系统引导性能分析

Systemd提供了工具用于识别和定位引导相关的问题或性能影响。Systemd-analyze是一个内建的命令，可以用来检测引导过程。你可以找出在启动过程中出错的单元，然后跟踪并改正引导组件的问题。在下面列出一些常用的systemd-analyze命令。

systemd-analyze time 用于显示内核和普通用户空间启动时所花的时间。

$ systemd-analyze time

Startup finished in 1440ms (kernel) + 3444ms (userspace)

systemd-analyze blame 会列出所有正在运行的单元，按从初始化开始到当前所花的时间排序，通过这种方式你就知道哪些服务在引导过程中要花较长时间来启动。

$ systemd-analyze blame

2001ms mysqld.service
234ms httpd.service
191ms vmms.service

systemd-analyze verify 显示在所有系统单元中是否有语法错误。

systemd-analyze plot 可以用来把整个引导过程写入一个SVG格式文件里。整个引导过程非常长不方便阅读，所以通过这个命令我们可以把输出写入一个文件，之后再查看和分析。下面这个命令就是做这个。

systemd-analyze plot > boot.svg

Systemd的争议

Systemd并没有幸运地获得所有人的青睐，一些专家和管理员对于它的工作方式和开发有不同意见。根据对于Systemd的批评，它不是“类Unix”方式因为它试着替换一些系统服务。一些专家也不喜欢使用二进制配置文件的想法。据说编辑systemd配置非常困难而且没有一个可用的图形工具。

如何在Ubuntu 14.04和12.04上测试Systemd

本来，Ubuntu决定从Ubuntu 16.04 LTS开始使用Systemd来替换当前的引导过程。Ubuntu 16.04预计在2016年4月发布，但是考虑到Systemd的流行和需求，刚刚发布的Ubuntu 15.04采用它作为默认引导程序。另外，Ubuntu 14.04 Trusty Tahr和Ubuntu 12.04 Precise Pangolin的用户可以在他们的机器上测试Systemd。测试过程并不复杂，你所要做的只是把相关的PPA包含到系统中，更新仓库并升级系统。

声明：请注意它仍然处于Ubuntu的测试和开发阶段。升级测试包可能会带来一些未知错误，最坏的情况下有可能损坏你的系统配置。请确保在尝试升级前已经备份好重要数据。

在终端里运行下面的命令来添加PPA到你的Ubuntu系统里：

sudo add-apt-repository ppa:pitti/systemd

你将会看到警告信息因为我们尝试使用临时/测试PPA，而它们是不建议用于实际工作机器上的。

然后运行下面的命令更新APT包管理仓库。

sudo apt-get update

运行下面的命令升级系统。

sudo apt-get dist-upgrade

就这些，你应该已经可以在你的Ubuntu系统里看到Systemd配置文件了，打开/lib/systemd/目录可以看到这些文件。

好吧，现在让我们编辑一下grub配置文件指定systemd作为默认引导程序。可以使用Gedit文字编辑器编辑grub配置文件。

sudo gedit /etc/default/grub

在文件里修改GRUBCMDLINELINUX\_DEFAULT项，设定它的参数为：“init=/lib/systemd/systemd”

就这样，你的Ubuntu系统已经不再使用传统的引导程序了，改为使用Systemd管理器。重启你的机器然后查看systemd引导过程吧。

结论

Systemd毫无疑问为改进Linux引导过程前进了一大步；它包含了一套漂亮的库和守护进程配合工作来优化系统引导和关闭过程。许多Linux发行版正准备将它作为自己的正式引导程序。在以后的Linux发行版中，我们将有望看到systemd开机。但是另一方面，为了获得成功并广泛应用，systemd仍需要认真处理批评意见。

via: http://linoxide.com/linux-how-to/systemd-boot-process/

作者：Aun Raza 译者：zpl1025 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

简介

对于您的站点的访问者来说，智能化的内容缓存是提高用户体验最有效的方式之一。缓存，或者对之前的请求的临时存储，是HTTP协议实现中最核心的内容分发策略之一。分发路径中的组件均可以缓存内容来加速后续的请求，这受控于对该内容所声明的缓存策略。

在这份指南中，我们将讨论一些Web内容缓存的基本概念。这主要包括如何选择缓存策略以保证互联网范围内的缓存能够正确的处理您的内容。我们将谈一谈缓存带来的好处、副作用以及不同的策略能带来的性能和灵活性的最大结合。

什么是缓存（caching）？

缓存（caching）是一个描述存储可重用资源以便加快后续请求的行为的术语。有许多不同类型的缓存，每种都有其自身的特点，应用程序缓存和内存缓存由于其对特定回复的加速，都很常用。

这份指南的主要讲述的Web缓存是一种不同类型的缓存。Web缓存是HTTP协议的一个核心特性，它能最小化网络流量，并且提升用户所感知的整个系统响应速度。内容从服务器到浏览器的传输过程中，每个层面都可以找到缓存的身影。

Web缓存根据特定的规则缓存相应HTTP请求的响应。对于缓存内容的后续请求便可以直接由缓存满足而不是重新发送请求到Web服务器。

好处

有效的缓存技术不仅可以帮助用户，还可以帮助内容的提供者。缓存对内容分发带来的好处有：

• 减少网络开销：内容可以在从内容提供者到内容消费者网络路径之间的许多不同的地方被缓存。当内容在距离内容消费者更近的地方被缓存时，由于缓存的存在，请求将不会消耗额外的网络资源。
• 加快响应速度：由于并不是必须通过整个网络往返，缓存可以使内容的获得变得更快。缓存放在距用户更近的地方，例如浏览器缓存，使得内容的获取几乎是瞬时的。
• 在同样的硬件上提高速度：对于保存原始内容的服务器来说，更多的性能可以通过允许激进的缓存策略从硬件上压榨出来。内容拥有者们可以利用分发路径上某个强大的服务器来应对特定内容负载的冲击。
• 网络中断时内容依旧可用：使用某种策略，缓存可以保证在原始服务器变得不可用时，相应的内容对用户依旧可用。

术语

在面对缓存时，您可能对一些经常遇到的术语可能不太熟悉。一些常见的术语如下：

• 原始服务器：原始服务器是内容的原始存放地点。如果您是Web服务器管理员，它就是您所管理的机器。它负责为任何不能从缓存中得到的内容进行回复，并且负责设置所有内容的缓存策略。
• 缓存命中率：一个缓存的有效性依照缓存的命中率进行度量。它是可以从缓存中得到数据的请求数与所有请求数的比率。缓存命中率高意味着有很高比例的数据可以从缓存中获得。这通常是大多数管理员想要的结果。
• 新鲜度：新鲜度用来描述一个缓存中的项目是否依旧适合返回给客户端。缓存中的内容只有在由缓存策略指定的新鲜期内才会被返回。
• 过期内容：缓存中根据缓存策略的新鲜期设置已过期的内容。过期的内容被标记为“陈旧”。通常，过期内容不能用于回复客户端的请求。必须重新从原始服务器请求新的内容或者至少验证缓存的内容是否仍然准确。
• 校验：缓存中的过期内容可以验证是否有效以便刷新过期时间。验证过程包括联系原始服务器以检查缓存的数据是否依旧代表了最近的版本。
• 失效：失效是依据过期日期从缓存中移除内容的过程。当内容在原始服务器上已被改变时就必须这样做，缓存中过期的内容会导致客户端发生问题。

还有许多其他的缓存术语，不过上面的这些应该能帮助您开始。

什么能被缓存？

某些特定的内容比其他内容更容易被缓存。对大多数站点来说，一些适合缓存的内容如下：

• Logo和商标图像
• 普通的不变化的图像（例如，导航图标）
• CSS样式表
• 普通的Javascript文件
• 可下载的内容
• 媒体文件

这些文件更倾向于不经常改变，所以长时间的对它们进行缓存能获得好处。

一些项目在缓存中必须加以注意：

• HTML页面
• 会替换改变的图像
• 经常修改的Javascript和CSS文件
• 需要有认证后的cookies才能访问的内容

一些内容从来不应该被缓存：

• 与敏感信息相关的资源（银行数据，等）
• 用户相关且经常更改的数据

除上面的通用规则外，通常您需要指定一些规则以便于更好地缓存不同种类的内容。例如，如果登录的用户都看到的是同样的网站视图，就应该在任何地方缓存这个页面。如果登录的用户会在一段时间内看到站点中用户特定的视图，您应该让用户的浏览器缓存该数据而不应让任何中介节点缓存该视图。

Web内容缓存的位置

Web内容会在整个分发路径中的许多不同的位置被缓存：

• 浏览器缓存：Web浏览器自身会维护一个小型缓存。典型地，浏览器使用一种策略指示缓存最重要的内容。这可能是用户相关的内容或可能会再次请求且下载代价较高。
• 中间缓存代理：任何在客户端和您的基础架构之间的服务器都可以按期望缓存一些内容。这些缓存可能由ISP（网络服务提供者）或者其他独立组织提供。
• 反向缓存：您的服务器基础架构可以为后端的服务实现自己的缓存。如果实现了缓存，那么便可以在处理请求的位置返回相应的内容而不用每次请求都使用后端服务。

上面的这些位置通常都可以根据它们自身的缓存策略和内容源的缓存策略缓存一些相应的内容。

缓存头部

缓存策略依赖于两个不同的因素。所缓存的实体本身需要决定是否应该缓存可接受的内容。它可以只缓存部分可以缓存的内容，但不能缓存超过限制的内容。

缓存行为主要由缓存策略决定，而缓存策略由内容拥有者设置。这些策略主要通过特定的HTTP头部来清晰地表达。

经过几个不同HTTP协议的变化，出现了一些不同的针对缓存方面的头部，它们的复杂度各不相同。下面列出了那些你也许应该注意的：

• **Expires**：尽管使用范围相当有限，但Expires头部是非常简洁明了的。通常它设置一个未来的时间，内容会在此时间过期。这时，任何对同样内容的请求都应该回到原始服务器处。这个头部或许仅仅最适合回退模式（fall back）。
• **Cache-Control**：这是Expires的一个更加现代化的替换物。它已被很好的支持，且拥有更加灵活的实现。在大多数案例中，它比Expires更好，但同时设置两者的值也无妨。稍后我们将讨论您可以设置的Cache-Control的详细选项。
• **ETag**：ETag用于缓存验证。源服务器可以在首次服务一个内容时为该内容提供一个独特的ETag。当一个缓存需要验证这个内容是否即将过期，他会将相应的ETag发送回服务器。源服务器或者告诉缓存内容是一致的，或者发送更新后的内容（带着新的ETag）。
• Last-Modified：这个头部指明了相应的内容最后一次被修改的时间。它可能会作为保证内容新鲜度的验证策略的一部分被使用。
• **Content-Length**：尽管并没有在缓存中明确涉及，Content-Length头部在设置缓存策略时很重要。某些软件如果不提前获知内容的大小以留出足够空间，则会拒绝缓存该内容。
• **Vary**：缓存系统通常使用请求的主机和路径作为存储该资源的键。当判断一个请求是否是请求同样内容时，Vary头部可以被用来提醒缓存系统需要注意另一个附加头部。它通常被用来告诉缓存系统同样注意Accept-Encoding头部，以便缓存系统能够区分压缩和未压缩的内容。

Vary头部的隐语

Vary头部提供给您存储同一个内容的不同版本的能力，代价是降低了缓存的容量。

在使用Accept-Encoding时，设置Vary头部允许明确区分压缩和未压缩的内容。这在服务某些不能处理压缩数据的浏览器时很重要，它可以保证基本的可用性。Vary的一个典型的值是Accept-Encoding，它只有两到三个可选的值。

一开始看上去User-Agent这样的头部可以用于区分移动浏览器和桌面浏览器，以便您的站点提供差异化的服务。但User-Agent字符串是非标准的，结果将会造成在中间缓存中保存同一内容的许多不同版本的缓存，这会导致缓存命中率的降低。Vary头部应该谨慎使用，尤其是您不具备在您控制的中间缓存中使请求标准化的能力（也许可以，比如您可以控制CDN的话）。

缓存控制标志怎样影响缓存

上面我们提到了Cache-Control头部如何被用与现代缓存策略标准。能够通过这个头部设定许多不同的缓存指令，多个不同的指令通过逗号分隔。

一些您可以使用的指示内容缓存策略的Cache-Control的选项如下：

• no-cache：这个指令指示所有缓存的内容在新的请求到达时必须先重新验证，再发送给客户端。这条指令实际将内容立刻标记为过期的，但允许通过验证手段重新验证以避免重新下载整个内容。
• no-store：这条指令指示缓存的内容不能以任何方式被缓存。它适合在回复敏感信息时设置。
• public：它将内容标记为公有的，这意味着它能被浏览器和其他任何中间节点缓存。通常，对于使用了HTTP验证的请求，其回复被默认标记为private。public标记将会覆盖这个设置。
• private：它将内容标记为私有的。私有数据可以被用户的浏览器缓存，但不能被任何中间节点缓存。它通常用于用户相关的数据。
• max-age：这个设置指示了缓存内容的最大生存期，它在最大生存期后必须在源服务器处被验证或被重新下载。在现代浏览器中这个选项大体上取代了Expires头部，浏览器也将其作为决定内容的新鲜度的基础。这个选项的值以秒为单位表示，最大可以表示一年的新鲜期（31536000秒）。
• s-maxage：这个选项非常类似于max-age，它指明了内容能够被缓存的时间。区别是这个选项只在中间节点的缓存中有效。结合这两个选项可以构建更加灵活的缓存策略。
• must-revalidate：它指明了由max-age、s-maxage或Expires头部指明的新鲜度信息必须被严格的遵守。它避免了缓存的数据在网络中断等类似的场景中被使用。
• proxy-revalidate：它和上面的选项有着一样的作用，但只应用于中间的代理节点。在这种情况下，用户的浏览器可以在网络中断时使用过期内容，但中间缓存内容不能用于此目的。
• no-transform：这个选项告诉缓存在任何情况下都不能因为性能的原因修改接收到的内容。这意味着，缓存不允许压缩接收到的内容（没有从原始服务器处接收过压缩版本的该内容）并发送。

这些选项能够以不同的方式结合以获得不同的缓存行为。一些互斥的值如下：

• no-cache，no-store以及由其他前面未提到的选项指明的常用的缓存行为
• public和private

如果no-store和no-cache都被设置，那么no-store会取代no-cache。对于非授权的请求的回复，public是隐含的设置。对于授权的请求的回复，private选项是隐含的。他们可以通过在Cache-Control头部中指明相应的相反的选项以覆盖。

开发一种缓存策略

在理想情况下，任何内容都可以被尽可能缓存，而您的服务器只需要偶尔的提供一些验证内容即可。但这在现实中很少发生，因此您应该尝试设置一些明智的缓存策略，以在长期缓存和站点改变的需求间达到平衡。

常见问题

在许多情况中，由于内容被产生的方式（如根据每个用户动态的产生）或者内容的特性（例如银行的敏感数据），这些内容不应该被缓存。另一些许多管理员在设置缓存时可能面对的问题是外部缓存的数据未过期，但新版本的数据已经产生。

这些都是经常遇到的问题，它们会影响缓存的性能和您提供的数据的准确性。然而，我们可以通过开发提前预见这些问题的缓存策略来缓解这些问题。

一般性建议

尽管您的实际情况会指导您选择的缓存策略，但是下面的建议能帮助您获得一些合理的决定。

在您担心使用哪一个特定的头部之前，有一些特定的步骤可以帮助您提高您的缓存命中率。一些建议如下：

• 为图像、CSS和共享的内容建立特定的文件夹：将内容放到特定的文件夹内使得您可以方便的从您的站点中的任何页面引用这些内容。
• 使用同样的URL来表示同样的内容：由于缓存使用内容请求中的主机名和路径作为键，因此应保证您的所有页面中的该内容的引用方式相同，前一个建议能让这点更加容易做到。
• 尽可能使用CSS图像拼接：对于像图标和导航等内容，使用CSS图像拼接能够减少渲染您页面所需要的请求往返，并且允许对拼接缓存很长一段时间。
• 尽可能将主机脚本和外部资源本地化：如果您使用Javascript脚本和其他外部资源，如果上游没有提供合适的缓存头部，那么您应考虑将这些内容放在您自己的服务器上。您应该注意上游的任何更新，以便更新本地的拷贝。
• 对缓存内容收集文件摘要：静态的内容比如CSS和Javascript文件等通常比较适合收集文件摘要。这意味着为文件名增加一个独特的标志符（通常是这个文件的哈希值）可以在文件修改后绕开缓存保证新的内容被重新获取。有很多工具可以帮助您创建文件摘要并且修改HTML文档中的引用。

对于不同的文件正确地选择不同的头部这件事，下面的内容可以作为一般性的参考：

• 允许所有的缓存存储一般内容：静态内容以及非用户相关的内容应该在分发链的所有节点被缓存。这使得中间节点可以将该内容回复给多个用户。
• 允许浏览器缓存用户相关的内容：对于每个用户的数据，通常在用户自己的浏览器中缓存是可以被接受且有益的。缓存在用户自身的浏览器能够使得用户在接下来的浏览中能够瞬时读取，但这些内容不适合在任何中间代理节点缓存。
• 将时间敏感的内容作为特例：如果您的数据是时间敏感的，那么相对上面两条参考，应该将这些数据作为特例，以保证过期的数据不会在关键的情况下被使用。例如，您的站点有一个购物车，它应该立刻反应购物车里面的物品。依据内容的特点，可以在Cache-Control头部中使用no-cache或no-store选项。
• 总是提供验证器：验证器使得过期的内容可以无需重新下载而得到刷新。设置ETag和Last-Modified头部将允许缓存向原始服务器验证内容，并在内容未修改时刷新该内容新鲜度以减少负载。
• 对于支持的内容设置长的新鲜期：为了更加有效的利用缓存，一些作为支持性的内容应该被设置较长的新鲜期。这通常比较适合图像和CSS等由用户请求用来渲染HTML页面的内容。和文件摘要一起，设置延长的新鲜期将允许缓存长时间的存储这些资源。如果资源发生改变，修改的文件摘要将会使缓存的数据无效并触发对新的内容的下载。那时，新的支持的内容会继续被缓存。
• 对父内容设置短的新鲜期：为了使得前面的模式正常工作，容器类的内容应该相应的设置短的新鲜期，或者设置不全部缓存。这通常是在其他协助内容中使用的HTML页面。这个HTML页面将会被频繁的下载，使得它能快速的响应改变。支持性的内容因此可以被尽量缓存。

关键之处便在于达到平衡，一方面可以尽量的进行缓存，另一方面为未来保留当改变发生时从而改变整个内容的机会。您的站点应该同时具有：

• 尽量缓存的内容
• 拥有短的新鲜期的缓存内容，可以被重新验证
• 完全不被缓存的内容

这样做的目的便是将内容尽可能的移动到第一个分类（尽量缓存）中的同时，维持可以接受的缓存命中率。

结论

花时间确保您的站点使用了合适的缓存策略将对您的站点产生重要的影响。缓存使得您可以在保证服务同样内容的同时减少带宽的使用。您的服务器因此可以靠同样的硬件处理更多的流量。或许更重要的是，客户们能在您的网站中获得更快的体验，这会使得他们更愿意频繁的访问您的站点。尽管有效的Web缓存并不是银弹，但设置合适的缓存策略会使您以最小的代价获得可观的收获。

via: https://www.digitalocean.com/community/tutorials/web-caching-basics-terminology-http-headers-and-caching-strategies

作者: Justin Ellingwood 译者：wwy-hust 校对：wxy 推荐：royaso

本文由 LCTT 原创翻译，Linux中国 荣誉推出