分类 系统运维 下的文章

现在的新闻里充斥着服务器被攻击和数据失窃事件。对于一个阅读过安全公告博客的人来说,通过访问错误配置的服务器,利用最新暴露的安全漏洞或通过窃取的密码来获得系统控制权,并不是件多困难的事情。在一个典型的 Linux 服务器上的任何互联网服务都可能存在漏洞,允许未经授权的系统访问。

因为在应用程序层面上强化系统以防范任何可能的威胁是不可能做到的事情,而防火墙可以通过限制对系统的访问提供了安全保证。防火墙基于源 IP、目标端口和协议来过滤入站包。因为这种方式中,仅有几个 IP/端口/协议的组合与系统交互,而其它的方式做不到过滤。

Linux 防火墙是通过 netfilter 来处理的,它是内核级别的框架。这十几年来,iptables 被作为 netfilter 的用户态抽象层(LCTT 译注: userland,一个基本的 UNIX 系统是由 kernel 和 userland 两部分构成,除 kernel 以外的称为 userland)。iptables 将包通过一系列的规则进行检查,如果包与特定的 IP/端口/协议的组合匹配,规则就会被应用到这个包上,以决定包是被通过、拒绝或丢弃。

Firewalld 是最新的 netfilter 用户态抽象层。遗憾的是,由于缺乏描述多区域配置的文档,它强大而灵活的功能被低估了。这篇文章提供了一个示例去改变这种情况。

Firewalld 的设计目标

firewalld 的设计者认识到大多数的 iptables 使用案例仅涉及到几个单播源 IP,仅让每个符合白名单的服务通过,而其它的会被拒绝。这种模式的好处是,firewalld 可以通过定义的源 IP 和/或网络接口将入站流量分类到不同 区域 zone 。每个区域基于指定的准则按自己配置去通过或拒绝包。

另外的改进是基于 iptables 进行语法简化。firewalld 通过使用服务名而不是它的端口和协议去指定服务,使它更易于使用,例如,是使用 samba 而不是使用 UDP 端口 137 和 138 和 TCP 端口 139 和 445。它进一步简化语法,消除了 iptables 中对语句顺序的依赖。

最后,firewalld 允许交互式修改 netfilter,允许防火墙独立于存储在 XML 中的永久配置而进行改变。因此,下面的的临时修改将在下次重新加载时被覆盖:

# firewall-cmd <some modification>

而,以下的改变在重加载后会永久保存:

# firewall-cmd --permanent <some modification>
# firewall-cmd --reload

区域

在 firewalld 中最上层的组织是区域。如果一个包匹配区域相关联的网络接口或源 IP/掩码 ,它就是区域的一部分。可用的几个预定义区域:

# firewall-cmd --get-zones
block dmz drop external home internal public trusted work

任何配置了一个网络接口和/或一个的区域就是一个 活动区域 active zone 。列出活动的区域:

# firewall-cmd --get-active-zones
public
  interfaces: eno1 eno2

Interfaces (接口)是系统中的硬件和虚拟的网络适配器的名字,正如你在上面的示例中所看到的那样。所有的活动的接口都将被分配到区域,要么是默认的区域,要么是用户指定的一个区域。但是,一个接口不能被分配给多于一个的区域。

在缺省配置中,firewalld 设置所有接口为 public 区域,并且不对任何区域设置源。其结果是,public 区域是唯一的活动区域。

Sources (源)是入站 IP 地址的范围,它也可以被分配到区域。一个源(或重叠的源)不能被分配到多个区域。这样做的结果是产生一个未定义的行为,因为不清楚应该将哪些规则应用于该源。

因为指定一个源不是必需的,任何包都可以通过接口匹配而归属于一个区域,而不需要通过源匹配来归属一个区域。这表示通过使用优先级方式,优先到达多个指定的源区域,稍后将详细说明这种情况。首先,我们来检查 public 区域的配置:

# firewall-cmd --zone=public --list-all
public (default, active)
  interfaces: eno1 eno2
  sources:
  services: dhcpv6-client ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:
# firewall-cmd --permanent --zone=public --get-target
default

逐行说明如下:

  • public (default, active) 表示 public 区域是默认区域(当接口启动时会自动默认),并且它是活动的,因为,它至少有一个接口或源分配给它。
  • interfaces: eno1 eno2 列出了这个区域上关联的接口。
  • sources: 列出了这个区域的源。现在这里什么都没有,但是,如果这里有内容,它们应该是这样的格式 xxx.xxx.xxx.xxx/xx。
  • services: dhcpv6-client ssh 列出了允许通过这个防火墙的服务。你可以通过运行 firewall-cmd --get-services 得到一个防火墙预定义服务的详细列表。
  • ports: 列出了一个允许通过这个防火墙的目标端口。它是用于你需要去允许一个没有在 firewalld 中定义的服务的情况下。
  • masquerade: no 表示这个区域是否允许 IP 伪装。如果允许,它将允许 IP 转发,它可以让你的计算机作为一个路由器。
  • forward-ports: 列出转发的端口。
  • icmp-blocks: 阻塞的 icmp 流量的黑名单。
  • rich rules: 在一个区域中优先处理的高级配置。
  • default 是目标区域,它决定了与该区域匹配而没有由上面设置中显式处理的包的动作。

一个简单的单区域配置示例

如果只是简单地锁定你的防火墙。简单地在删除公共区域上当前允许的服务,并重新加载:

# firewall-cmd --permanent --zone=public --remove-service=dhcpv6-client
# firewall-cmd --permanent --zone=public --remove-service=ssh
# firewall-cmd --reload

在下面的防火墙上这些命令的结果是:

# firewall-cmd --zone=public --list-all
public (default, active)
  interfaces: eno1 eno2
  sources:
  services:
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:
# firewall-cmd --permanent --zone=public --get-target
default

本着尽可能严格地保证安全的精神,如果发生需要在你的防火墙上临时开放一个服务的情况(假设是 ssh),你可以增加这个服务到当前会话中(省略 --permanent),并且指示防火墙在一个指定的时间之后恢复修改:

# firewall-cmd --zone=public --add-service=ssh --timeout=5m

这个 timeout 选项是一个以秒(s)、分(m)或小时(h)为单位的时间值。

目标

当一个区域处理它的源或接口上的一个包时,但是,没有处理该包的显式规则时,这时区域的 目标 target 决定了该行为:

  • ACCEPT:通过这个包。
  • %%REJECT%%:拒绝这个包,并返回一个拒绝的回复。
  • DROP:丢弃这个包,不回复任何信息。
  • default:不做任何事情。该区域不再管它,把它踢到“楼上”。

在 firewalld 0.3.9 中有一个 bug (已经在 0.3.10 中修复),对于一个目标是除了“default”以外的源区域,不管允许的服务是什么,这的目标都会被应用。例如,一个使用目标 DROP 的源区域,将丢弃所有的包,甚至是白名单中的包。遗憾的是,这个版本的 firewalld 被打包到 RHEL7 和它的衍生版中,使它成为一个相当常见的 bug。本文中的示例避免了可能出现这种行为的情况。

优先权

活动区域中扮演两个不同的角色。关联接口行为的区域作为接口区域,并且,关联源行为的区域作为源区域(一个区域能够扮演两个角色)。firewalld 按下列顺序处理一个包:

  1. 相应的源区域。可以存在零个或一个这样的区域。如果这个包满足一个 富规则 rich rule 、服务是白名单中的、或者目标没有定义,那么源区域处理这个包,并且在这里结束。否则,向上传递这个包。
  2. 相应的接口区域。肯定有一个这样的区域。如果接口处理这个包,那么到这里结束。否则,向上传递这个包。
  3. firewalld 默认动作。接受 icmp 包并拒绝其它的一切。

这里的关键信息是,源区域优先于接口区域。因此,对于多区域的 firewalld 配置的一般设计模式是,创建一个优先源区域来允许指定的 IP 对系统服务的提升访问,并在一个限制性接口区域限制其它访问。

一个简单的多区域示例

为演示优先权,让我们在 public 区域中将 http 替换成 ssh,并且为我们喜欢的 IP 地址,如 1.1.1.1,设置一个默认的 internal 区域。以下的命令完成这个任务:

# firewall-cmd --permanent --zone=public --remove-service=ssh
# firewall-cmd --permanent --zone=public --add-service=http
# firewall-cmd --permanent --zone=internal --add-source=1.1.1.1
# firewall-cmd --reload

这些命令的结果是生成如下的配置:

# firewall-cmd --zone=public --list-all
public (default, active)
  interfaces: eno1 eno2
  sources:
  services: dhcpv6-client http
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:
# firewall-cmd --permanent --zone=public --get-target
default
# firewall-cmd --zone=internal --list-all
internal (active)
  interfaces:
  sources: 1.1.1.1
  services: dhcpv6-client mdns samba-client ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:
# firewall-cmd --permanent --zone=internal --get-target
default

在上面的配置中,如果有人尝试从 1.1.1.1 去 ssh,这个请求将会成功,因为这个源区域(internal)被首先应用,并且它允许 ssh 访问。

如果有人尝试从其它的地址,如 2.2.2.2,去访问 ssh,它不是这个源区域的,因为和这个源区域不匹配。因此,这个请求被直接转到接口区域(public),它没有显式处理 ssh,因为,public 的目标是 default,这个请求被传递到默认动作,它将被拒绝。

如果 1.1.1.1 尝试进行 http 访问会怎样?源区域(internal)不允许它,但是,目标是 default,因此,请求将传递到接口区域(public),它被允许访问。

现在,让我们假设有人从 3.3.3.3 拖你的网站。要限制从那个 IP 的访问,简单地增加它到预定义的 drop 区域,正如其名,它将丢弃所有的连接:

# firewall-cmd --permanent --zone=drop --add-source=3.3.3.3
# firewall-cmd --reload

下一次 3.3.3.3 尝试去访问你的网站,firewalld 将转发请求到源区域(drop)。因为目标是 DROP,请求将被拒绝,并且它不会被转发到接口区域(public)。

一个实用的多区域示例

假设你为你的组织的一台服务器配置防火墙。你希望允许全世界使用 httphttps 的访问,你的组织(1.1.0.0/16)和工作组(1.1.1.0/8)使用 ssh 访问,并且你的工作组可以访问 samba 服务。使用 firewalld 中的区域,你可以用一个很直观的方式去实现这个配置。

public 这个命名,它的逻辑似乎是把全世界访问指定为公共区域,而 internal 区域用于为本地使用。从在 public 区域内设置使用 httphttps 替换 dhcpv6-clientssh 服务来开始:

# firewall-cmd --permanent --zone=public --remove-service=dhcpv6-client
# firewall-cmd --permanent --zone=public --remove-service=ssh
# firewall-cmd --permanent --zone=public --add-service=http
# firewall-cmd --permanent --zone=public --add-service=https

然后,取消 internal 区域的 mdnssamba-clientdhcpv6-client 服务(仅保留 ssh),并增加你的组织为源:

# firewall-cmd --permanent --zone=internal --remove-service=mdns
# firewall-cmd --permanent --zone=internal --remove-service=samba-client
# firewall-cmd --permanent --zone=internal --remove-service=dhcpv6-client
# firewall-cmd --permanent --zone=internal --add-source=1.1.0.0/16

为容纳你提升的 samba 的权限,增加一个富规则:

# firewall-cmd --permanent --zone=internal --add-rich-rule='rule family=ipv4 source address="1.1.1.0/8" service name="samba" accept'

最后,重新加载,把这些变化拉取到会话中:

# firewall-cmd --reload

仅剩下少数的细节了。从一个 internal 区域以外的 IP 去尝试通过 ssh 到你的服务器,结果是回复一个拒绝的消息。它是 firewalld 默认的。更为安全的作法是去显示不活跃的 IP 行为并丢弃该连接。改变 public 区域的目标为 DROP,而不是 default 来实现它:

# firewall-cmd --permanent --zone=public --set-target=DROP
# firewall-cmd --reload

但是,等等,你不再可以 ping 了,甚至是从内部区域!并且 icmp (ping 使用的协议)并不在 firewalld 可以列入白名单的服务列表中。那是因为,icmp 是第 3 层的 IP 协议,它没有端口的概念,不像那些捆绑了端口的服务。在设置公共区域为 DROP 之前,ping 能够通过防火墙是因为你的 default 目标通过它到达防火墙的默认动作(default),即允许它通过。但现在它已经被删除了。

为恢复内部网络的 ping,使用一个富规则:

# firewall-cmd --permanent --zone=internal --add-rich-rule='rule protocol value="icmp" accept'
# firewall-cmd --reload

结果如下,这里是两个活动区域的配置:

# firewall-cmd --zone=public --list-all
public (default, active)
  interfaces: eno1 eno2
  sources:
  services: http https
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:
# firewall-cmd --permanent --zone=public --get-target
DROP
# firewall-cmd --zone=internal --list-all
internal (active)
  interfaces:
  sources: 1.1.0.0/16
  services: ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:
        rule family=ipv4 source address="1.1.1.0/8" service name="samba" accept
        rule protocol value="icmp" accept
# firewall-cmd --permanent --zone=internal --get-target
default

这个设置演示了一个三层嵌套的防火墙。最外层,public,是一个接口区域,包含全世界的访问。紧接着的一层,internal,是一个源区域,包含你的组织,它是 public 的一个子集。最后,一个富规则增加到最内层,包含了你的工作组,它是 internal 的一个子集。

这里的关键信息是,当在一个场景中可以突破到嵌套层,最外层将使用接口区域,接下来的将使用一个源区域,并且在源区域中额外使用富规则。

调试

firewalld 采用直观范式来设计防火墙,但比它的前任 iptables 更容易产生歧义。如果产生无法预料的行为,或者为了更好地理解 firewalld 是怎么工作的,则可以使用 iptables 描述 netfilter 是如何配置操作的。前一个示例的输出如下,为了简单起见,将输出和日志进行了修剪:

# iptables -S
-P INPUT ACCEPT
... (forward and output lines) ...
-N INPUT_ZONES
-N INPUT_ZONES_SOURCE
-N INPUT_direct
-N IN_internal
-N IN_internal_allow
-N IN_internal_deny
-N IN_public
-N IN_public_allow
-N IN_public_deny
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_ZONES_SOURCE
-A INPUT -j INPUT_ZONES
-A INPUT -p icmp -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -j REJECT --reject-with icmp-host-prohibited
... (forward and output lines) ...
-A INPUT_ZONES -i eno1 -j IN_public
-A INPUT_ZONES -i eno2 -j IN_public
-A INPUT_ZONES -j IN_public
-A INPUT_ZONES_SOURCE -s 1.1.0.0/16 -g IN_internal
-A IN_internal -j IN_internal_deny
-A IN_internal -j IN_internal_allow
-A IN_internal_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-A IN_internal_allow -s 1.1.1.0/8 -p udp -m udp --dport 137 -m conntrack --ctstate NEW -j ACCEPT
-A IN_internal_allow -s 1.1.1.0/8 -p udp -m udp --dport 138 -m conntrack --ctstate NEW -j ACCEPT
-A IN_internal_allow -s 1.1.1.0/8 -p tcp -m tcp --dport 139 -m conntrack --ctstate NEW -j ACCEPT
-A IN_internal_allow -s 1.1.1.0/8 -p tcp -m tcp --dport 445 -m conntrack --ctstate NEW -j ACCEPT
-A IN_internal_allow -p icmp -m conntrack --ctstate NEW -j ACCEPT
-A IN_public -j IN_public_deny
-A IN_public -j IN_public_allow
-A IN_public -j DROP
-A IN_public_allow -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT

在上面的 iptables 输出中,新的链(以 -N 开始的行)是被首先声明的。剩下的规则是附加到(以 -A 开始的行) iptables 中的。已建立的连接和本地流量是允许通过的,并且入站包被转到 INPUT_ZONES_SOURCE 链,在那里如果存在相应的区域,IP 将被发送到那个区域。从那之后,流量被转到 INPUT_ZONES 链,从那里它被路由到一个接口区域。如果在那里它没有被处理,icmp 是允许通过的,无效的被丢弃,并且其余的都被拒绝。

结论

firewalld 是一个文档不足的防火墙配置工具,它的功能远比大多数人认识到的更为强大。以创新的区域范式,firewalld 允许系统管理员去分解流量到每个唯一处理它的分类中,简化了配置过程。因为它直观的设计和语法,它在实践中不但被用于简单的单一区域中也被用于复杂的多区域配置中。


via: https://www.linuxjournal.com/content/understanding-firewalld-multi-zone-configurations

作者:Nathan Vance 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

没有时间运行命令?使用 cron 的计划任务意味着你不用熬夜程序也可以运行。

系统管理员(在许多好处中)的挑战之一是在你该睡觉的时候去运行一些任务。例如,一些任务(包括定期循环运行的任务)需要在没有人使用计算机资源的时候去运行,如午夜或周末。在下班后,我没有时间去运行命令或脚本。而且,我也不想在晚上去启动备份或重大更新。

取而代之的是,我使用两个服务功能在我预定的时间去运行命令、程序和任务。cron 和 at 服务允许系统管理员去安排任务运行在未来的某个特定时间。at 服务指定在某个时间去运行一次任务。cron 服务可以安排任务在一个周期上重复,比如天、周、或月。

在这篇文章中,我将介绍 cron 服务和怎么去使用它。

常见(和非常见)的 cron 用途

我使用 cron 服务去安排一些常见的事情,比如,每天凌晨 2:00 发生的定期备份,我也使用它去做一些不常见的事情。

  • 许多电脑上的系统时钟(比如,操作系统时间)都设置为使用网络时间协议(NTP)。 NTP 设置系统时间后,它不会去设置硬件时钟,它可能会“漂移”。我使用 cron 基于系统时间去设置硬件时钟。
  • 我还有一个 Bash 程序,我在每天早晨运行它,去在每台电脑上创建一个新的 “每日信息” (MOTD)。它包含的信息有当前的磁盘使用情况等有用的信息。
  • 许多系统进程和服务,像 Logwatchlogrotate、和 Rootkit Hunter,使用 cron 服务去安排任务和每天运行程序。

crond 守护进程是一个完成 cron 功能的后台服务。

cron 服务检查在 /var/spool/cron/etc/cron.d 目录中的文件,以及 /etc/anacrontab 文件。这些文件的内容定义了以不同的时间间隔运行的 cron 作业。个体用户的 cron 文件是位于 /var/spool/cron,而系统服务和应用生成的 cron 作业文件放在 /etc/cron.d 目录中。/etc/anacrontab 是一个特殊的情况,它将在本文中稍后部分介绍。

使用 crontab

cron 实用程序运行基于一个 cron 表(crontab)中指定的命令。每个用户,包括 root,都有一个 cron 文件。这些文件缺省是不存在的。但可以使用 crontab -e 命令创建在 /var/spool/cron 目录中,也可以使用该命令去编辑一个 cron 文件(看下面的脚本)。我强烈建议你,不要使用标准的编辑器(比如,Vi、Vim、Emacs、Nano、或者任何其它可用的编辑器)。使用 crontab 命令不仅允许你去编辑命令,也可以在你保存并退出编辑器时,重启动 crond 守护进程。crontab 命令使用 Vi 作为它的底层编辑器,因为 Vi 是预装的(至少在大多数的基本安装中是预装的)。

现在,cron 文件是空的,所以必须从头添加命令。 我增加下面示例中定义的作业到我的 cron 文件中,这是一个快速指南,以便我知道命令中的各个部分的意思是什么,你可以自由拷贝它,供你自己使用。

# crontab -e
SHELL=/bin/bash
[email protected]
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

# backup using the rsbu program to the internal 4TB HDD and then 4TB external
01 01 * * * /usr/local/bin/rsbu -vbd1 ; /usr/local/bin/rsbu -vbd2

# Set the hardware clock to keep it in sync with the more accurate system clock
03 05 * * * /sbin/hwclock --systohc

# Perform monthly updates on the first of the month
# 25 04 1 * * /usr/bin/dnf -y update

crontab 命令用于查看或编辑 cron 文件。

上面代码中的前三行设置了一个缺省环境。对于给定用户,环境变量必须是设置的,因为,cron 不提供任何方式的环境。SHELL 变量指定命令运行使用的 shell。这个示例中,指定为 Bash shell。MAILTO 变量设置发送 cron 作业结果的电子邮件地址。这些电子邮件提供了 cron 作业(备份、更新、等等)的状态,和你从命令行中手动运行程序时看到的结果是一样的。第三行为环境设置了 PATH 变量。但即使在这里设置了路径,我总是使用每个程序的完全限定路径。

在上面的示例中有几个注释行,它详细说明了定义一个 cron 作业所要求的语法。我将在下面分别讲解这些命令,然后,增加更多的 crontab 文件的高级特性。

01 01 * * * /usr/local/bin/rsbu -vbd1 ; /usr/local/bin/rsbu -vbd2

在我的 /etc/crontab 中的这一行运行一个脚本,用于为我的系统执行备份。

这一行运行我自己编写的 Bash shell 脚本 rsbu,它对我的系统做完全备份。这个作业每天的凌晨 1:01 (01 01) 运行。在这三、四、五位置上的星号(*),像文件通配符一样代表一个特定的时间,它们代表 “一个月中的每天”、“每个月” 和 “一周中的每天”,这一行会运行我的备份两次,一次备份内部专用的硬盘驱动器,另外一次运行是备份外部的 USB 驱动器,使用它这样我可以很保险。

接下来的行我设置了一个硬件时钟,它使用当前系统时钟作为源去设置硬件时钟。这一行设置为每天凌晨 5:03 分运行。

03 05 * * * /sbin/hwclock --systohc

这一行使用系统时间作为源来设置硬件时钟。

我使用的第三个也是最后一个的 cron 作业是去执行一个 dnfyum 更新,它在每个月的第一天的凌晨 04:25 运行,但是,我注释掉了它,以后不再运行。

# 25 04 1 * * /usr/bin/dnf -y update

这一行用于执行一个每月更新,但是,我也把它注释掉了。

其它的定时任务技巧

现在,让我们去做一些比基本知识更有趣的事情。假设你希望在每周四下午 3:00 去运行一个特别的作业:

00 15 * * Thu /usr/local/bin/mycronjob.sh

这一行会在每周四下午 3:00 运行 mycronjob.sh 这个脚本。

或者,或许你需要在每个季度末去运行一个季度报告。cron 服务没有为 “每个月的最后一天” 设置选项,因此,替代方式是使用下一个月的第一天,像如下所示(这里假设当作业准备运行时,报告所需要的数据已经准备好了)。

02 03 1 1,4,7,10 * /usr/local/bin/reports.sh

在季度末的下一个月的第一天运行这个 cron 作业。

下面展示的这个作业,在每天的上午 9:01 到下午 5:01 之间,每小时运行一次。

01 09-17 * * * /usr/local/bin/hourlyreminder.sh

有时,你希望作业在业务期间定时运行。

我遇到一个情况,需要作业在每二、三或四小时去运行。它需要用期望的间隔去划分小时,比如, */3 为每三个小时,或者 6-18/3 为上午 6 点到下午 6 点每三个小时运行一次。其它的时间间隔的划分也是类似的。例如,在分钟位置的表达式 */15 意思是 “每 15 分钟运行一次作业”。

*/5 08-18/2 * * * /usr/local/bin/mycronjob.sh

这个 cron 作业在上午 8:00 到下午 18:59 之间,每五分钟运行一次作业。

需要注意的一件事情是:除法表达式的结果必须是余数为 0(即整除)。换句话说,在这个例子中,这个作业被设置为在上午 8 点到下午 6 点之间的偶数小时每 5 分钟运行一次(08:00、08:05、 08:10、 08:15……18:55 等等),而不运行在奇数小时。另外,这个作业不能运行在下午 7:00 到上午 7:59 之间。(LCTT 译注:此处本文表述有误,根据正确情况修改)

我相信,你可以根据这些例子想到许多其它的可能性。

限制访问 cron

普通用户使用 cron 访问可能会犯错误,例如,可能导致系统资源(比如内存和 CPU 时间)被耗尽。为避免这种可能的问题, 系统管理员可以通过创建一个 /etc/cron.allow 文件去限制用户访问,它包含了一个允许去创建 cron 作业的用户列表。(不管是否列在这个列表中,)不能阻止 root 用户使用 cron。

通过阻止非 root 用户创建他们自己的 cron 作业,那也许需要将非 root 用户的 cron 作业添加到 root 的 crontab 中, “但是,等等!” 你说,“不是以 root 去运行这些作业?” 不一定。在这篇文章中的第一个示例中,出现在注释中的用户名字段可以用于去指定一个运行作业的用户 ID。这可以防止特定的非 root 用户的作业以 root 身份去运行。下面的示例展示了一个作业定义,它以 “student” 用户去运行这个作业:

04 07 * * * student /usr/local/bin/mycronjob.sh

如果没有指定用户,这个作业将以 contab 文件的所有者用户去运行,在这个情况中是 root。

cron.d

目录 /etc/cron.d 中是一些应用程序,比如 SpamAssassinsysstat 安装的 cron 文件。因为,这里没有 spamassassin 或者 sysstat 用户,这些程序需要一个位置去放置 cron 文件,因此,它们被放在 /etc/cron.d 中。

下面的 /etc/cron.d/sysstat 文件包含系统活动报告(SAR)相关的 cron 作业。这些 cron 文件和用户 cron 文件格式相同。

# Run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib64/sa/sa1 1 1
# Generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A

sysstat 包安装了 /etc/cron.d/sysstat cron 文件来运行程序生成 SAR。

该 sysstat cron 文件有两行执行任务。第一行每十分钟去运行 sa1 程序去收集数据,存储在 /var/log/sa 目录中的一个指定的二进制文件中。然后,在每天晚上的 23:53, sa2 程序运行来创建一个每日汇总。

计划小贴士

我在 crontab 文件中设置的有些时间看上起似乎是随机的,在某种程度上说,确实是这样的。尝试去安排 cron 作业可能是件很具有挑战性的事, 尤其是作业的数量越来越多时。我通常在我的每个电脑上仅有一些任务,它比起我工作用的那些生产和实验环境中的电脑简单多了。

我管理的一个系统有 12 个每天晚上都运行 cron 作业,另外 3、4 个在周末或月初运行。那真是个挑战,因为,如果有太多作业在同一时间运行,尤其是备份和编译系统,会耗尽内存并且几乎填满交换文件空间,这会导致系统性能下降甚至是超负荷,最终什么事情都完不成。我增加了一些内存并改进了如何计划任务。我还删除了一些写的很糟糕、使用大量内存的任务。

crond 服务假设主机计算机 24 小时运行。那意味着如果在一个计划运行的期间关闭计算机,这些计划的任务将不再运行,直到它们计划的下一次运行时间。如果这里有关键的 cron 作业,这可能导致出现问题。 幸运的是,在定期运行的作业上,还有一个其它的选择: anacron

anacron

anacron 程序执行和 cron 一样的功能,但是它增加了运行被跳过的作业的能力,比如,如果计算机已经关闭或者其它的原因导致无法在一个或多个周期中运行作业。它对笔记本电脑或其它被关闭或进行睡眠模式的电脑来说是非常有用的。

只要电脑一打开并引导成功,anacron 会检查过去是否有计划的作业被错过。如果有,这些作业将立即运行,但是,仅运行一次(而不管它错过了多少次循环运行)。例如,如果一个每周运行的作业在最近三周因为休假而系统关闭都没有运行,它将在你的电脑一启动就立即运行,但是,它仅运行一次,而不是三次。

anacron 程序提供了一些对周期性计划任务很好用的选项。它是安装在你的 /etc/cron.[hourly|daily|weekly|monthly] 目录下的脚本。 根据它们需要的频率去运行。

它是怎么工作的呢?接下来的这些要比前面的简单一些。

1、 crond 服务运行在 /etc/cron.d/0hourly 中指定的 cron 作业。

# Run the hourly jobs
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
01 * * * * root run-parts /etc/cron.hourly

/etc/cron.d/0hourly 中的内容使位于 /etc/cron.hourly 中的 shell 脚本运行。

2、 在 /etc/cron.d/0hourly 中指定的 cron 作业每小时运行一次 run-parts 程序。

3、 run-parts 程序运行所有的在 /etc/cron.hourly 目录中的脚本。

4、 /etc/cron.hourly 目录包含的 0anacron 脚本,它使用如下的 /etdc/anacrontab 配置文件去运行 anacron 程序。

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly

/etc/anacrontab 文件中的内容在合适的时间运行在 cron.[daily|weekly|monthly] 目录中的可执行文件。

5、 anacron 程序每日运行一次位于 /etc/cron.daily 中的作业。它每周运行一次位于 /etc/cron.weekly 中的作业。以及每月运行一次 cron.monthly 中的作业。注意,在每一行指定的延迟时间,它可以帮助避免这些作业与其它 cron 作业重叠。

我在 /usr/local/bin 目录中放置它们,而不是在 cron.X 目录中放置完整的 Bash 程序,这会使我从命令行中运行它们更容易。然后,我在 cron 目录中增加一个符号连接,比如,/etc/cron.daily

anacron 程序不是设计用于在指定时间运行程序的。而是,用于在一个指定的时间开始,以一定的时间间隔去运行程序,比如,从每天的凌晨 3:00(看上面脚本中的 START_HOURS_RANGE 行)、从周日(每周第一天)和这个月的第一天。如果任何一个或多个循环错过,anacron 将立即运行这个错过的作业。

更多的关于设置限制

我在我的计算机上使用了很多运行计划任务的方法。所有的这些任务都需要一个 root 权限去运行。在我的经验中,很少有普通用户去需要运行 cron 任务,一种情况是开发人员需要一个 cron 作业去启动一个开发实验室的每日编译。

限制非 root 用户去访问 cron 功能是非常重要的。然而,在一些特殊情况下,用户需要去设置一个任务在预先指定时间运行,而 cron 可以允许他们去那样做。许多用户不理解如何正确地配置 cron 去完成任务,并且他们会出错。这些错误可能是无害的,但是,往往不是这样的,它们可能导致问题。通过设置功能策略,使用户与管理员互相配合,可以使个别的 cron 作业尽可能地不干扰其它的用户和系统功能。

可以给为单个用户或组分配的资源设置限制,但是,这是下一篇文章中的内容。

更多信息,在 croncrontabanacronanacrontab、和 run-parts 的 man 页面上,所有的这些信息都描述了 cron 系统是如何工作的。


作者简介:

David Both - 是一位 Linux 和开源软件的倡导者,居住在 Raleigh,North Carolina。他从事 IT 行业超过四十年,并且在 IBM 教授 OS/2 超过 20 年时间,他在 1981 年 IBM 期间,为最初的 IBM PC 写了第一部培训教程。他为 Red Hat 教授 RHCE 系列课程,并且他也为 MCI Worldcom、 Cisco、和 North Carolina 州工作。他使用 Linux 和开源软件工作差不多 20 年了。


via: https://opensource.com/article/17/11/how-use-cron-linux

作者:David Both 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

用 iftop、Nethogs 和 vnstat 了解更多关于你的网络连接。

你可以通过这三个 Linux 网络命令,了解有关你网络连接的大量信息。iftop 通过进程号跟踪网络连接,Nethogs 可以快速显示哪个在占用你的带宽,而 vnstat 作为一个很好的轻量级守护进程运行,可以随时随地记录你的使用情况。

iftop

iftop 监听你指定的网络接口,并以 top 的形式展示连接。

这是一个很好的小工具,用于快速识别占用、测量速度,并保持网络流量的总体运行。看到我们使用了多少带宽是非常令人惊讶的,特别是对于我们这些还记得使用电话线、调制解调器、让人尖叫的 Kbit 速度和真实的实时波特率的老年人来说。我们很久以前就放弃了波特率,转而使用比特率。波特率测量信号变化,有时与比特率相同,但大多数情况下不是。

如果你只有一个网络接口,可以不带选项运行 iftopiftop 需要 root 权限:

$ sudo iftop

当你有多个接口时,指定要监控的接口:

$ sudo iftop -i wlan0

就像 top 一样,你可以在运行时更改显示选项。

  • h 切换帮助屏幕。
  • n 切换名称解析。
  • s 切换源主机显示,d 切换目标主机。
  • s 切换端口号。
  • N 切换端口解析。要全看到端口号,请关闭解析。
  • t 切换文本界面。默认显示需要 ncurses。我认为文本显示更易于阅读和更好的组织(图1)。
  • p 暂停显示。
  • q 退出程序。

 title=

图 1:文本显示是可读的和可组织的。

当你切换显示选项时,iftop 会继续测量所有流量。你还可以选择要监控的单个主机。你需要主机的 IP 地址和网络掩码。我很好奇 Pandora 在我那可怜的带宽中占用了多少,所以我先用 dig 找到它们的 IP 地址:

$ dig A pandora.com
[...]
;; ANSWER SECTION:
pandora.com.            267     IN      A       208.85.40.20
pandora.com.            267     IN      A       208.85.40.50

网络掩码是什么? ipcalc 告诉我们:

$ ipcalc -b 208.85.40.20
Address:   208.85.40.20   
Netmask:   255.255.255.0 = 24
Wildcard:  0.0.0.255  
=>
Network:   208.85.40.0/24 

现在将地址和网络掩码提供给 iftop:

$ sudo iftop -F 208.85.40.20/24 -i wlan0

这不是真的吗?我很惊讶地发现,我珍贵的带宽对于 Pandora 很宽裕,每小时使用大约使用 500Kb。而且,像大多数流媒体服务一样,Pandora 的流量也有峰值,其依赖于缓存来缓解阻塞。

你可以使用 -G 选项对 IPv6 地址执行相同操作。请参阅手册页了解 iftop 的其他功能,包括使用自定义配置文件定制默认选项,并应用自定义过滤器(请参阅 PCAP-FILTER 作为过滤器参考)。

Nethogs

当你想要快速了解谁占用了你的带宽时,Nethogs 是快速和容易的。以 root 身份运行,并指定要监听的接口。它显示了空闲的应用程序和进程号,以便如果你愿意的话,你可以杀死它:

$ sudo nethogs wlan0

NetHogs version 0.8.1

PID USER   PROGRAM              DEV    SENT   RECEIVED       
7690 carla /usr/lib/firefox     wlan0 12.494 556.580 KB/sec
5648 carla .../chromium-browser wlan0  0.052   0.038 KB/sec
TOTAL                                 12.546 556.618 KB/sec 

Nethogs 选项很少:在 kb/s、kb、b 和 mb 之间循环;通过接收或发送的数据包进行排序;并调整刷新之间的延迟。请参阅 man nethogs,或者运行 nethogs -h

vnstat

vnstat 是最容易使用的网络数据收集器。它是轻量级的,不需要 root 权限。它作为守护进程运行,并记录你网络统计信息。vnstat 命令显示累计的数据:

$ vnstat -i wlan0
Database updated: Tue Oct 17 08:36:38 2017

   wlan0 since 10/17/2017

          rx:  45.27 MiB      tx:  3.77 MiB      total:  49.04 MiB

   monthly
                     rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
       Oct '17     45.27 MiB |    3.77 MiB |   49.04 MiB |    0.28 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated        85 MiB |       5 MiB |      90 MiB |

   daily
                     rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
         today     45.27 MiB |    3.77 MiB |   49.04 MiB |   12.96 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated       125 MiB |       8 MiB |     133 MiB |

它默认显示所有的网络接口。使用 -i 选项选择单个接口。以这种方式合并多个接口的数据:

$ vnstat -i wlan0+eth0+eth1

你可以通过以下几种方式过滤显示:

  • -h 以小时显示统计数据。
  • -d 以天数显示统计数据。
  • -w-m 按周和月显示统计数据。
  • 使用 -l 选项查看实时更新。

此命令删除 wlan1 的数据库,并停止监控它:

$ vnstat -i wlan1 --delete

此命令为网络接口创建别名。此例使用 Ubuntu 16.04 中的一个奇怪的接口名称:

$ vnstat -u -i enp0s25 --nick eth0

默认情况下,vnstat 监视 eth0。你可以在 /etc/vnstat.conf 中更改此内容,或在主目录中创建自己的个人配置文件。请参见 man vnstat 以获得完整的参考。

你还可以安装 vnstati 创建简单的彩色图(图2):

$ vnstati -s -i wlx7cdd90a0a1c2 -o vnstat.png

 title=

图 2:你可以使用 vnstati 创建简单的彩色图表。

有关完整选项,请参见 man vnstati


via: https://www.linux.com/learn/intro-to-linux/2017/10/3-simple-excellent-linux-network-monitors

作者:CARLA SCHRODER 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

前段时间新的重大版本的 PostgreSQL 10 发布了! 强烈建议阅读公告发布说明和“新功能”概述可以在这里这里这里。像往常一样,已经有相当多的博客覆盖了所有新的东西,但我猜每个人都有自己认为重要的角度,所以与 9.6 版一样我再次在这里列出我印象中最有趣/相关的功能。

与往常一样,升级或初始化一个新集群的用户将获得更好的性能(例如,更好的并行索引扫描、合并 join 和不相关的子查询,更快的聚合、远程服务器上更加智能的 join 和聚合),这些都开箱即用,但本文中我想讲一些不能开箱即用,实际上你需要采取一些步骤才能从中获益的内容。下面重点展示的功能是从 DBA 的角度来汇编的,很快也有一篇文章从开发者的角度讲述更改。

升级注意事项

首先有些从现有设置升级的提示 - 有一些小的事情会导致从 9.6 或更旧的版本迁移时引起问题,所以在真正的升级之前,一定要在单独的副本上测试升级,并遍历发行说明中所有可能的问题。最值得注意的缺陷是:

  • 所有包含 “xlog” 的函数都被重命名为使用 “wal” 而不是 “xlog”。

后一个命名可能与正常的服务器日志混淆,因此这是一个“以防万一”的更改。如果使用任何第三方备份/复制/HA 工具,请检查它们是否为最新版本。

  • 存放服务器日志(错误消息/警告等)的 pg\_log 文件夹已重命名为 “log”。

确保验证你的日志解析或 grep 脚本(如果有)可以工作。

  • 默认情况下,查询将最多使用 2 个后台进程。

如果在 CPU 数量较少的机器上在 postgresql.conf 设置中使用默认值 10,则可能会看到资源使用率峰值,因为默认情况下并行处理已启用 - 这是一件好事,因为它应该意味着更快的查询。如果需要旧的行为,请将 max_parallel_workers_per_gather 设置为 0

  • 默认情况下,本地主机的复制连接已启用。

为了简化测试等工作,本地主机和本地 Unix 套接字复制连接现在在 pg_hba.conf 中以“ 信任 trust ”模式启用(无密码)!因此,如果其他非 DBA 用户也可以访问真实的生产计算机,请确保更改配置。

从 DBA 的角度来看我的最爱

  • 逻辑复制

这个期待已久的功能在你只想要复制一张单独的表、部分表或者所有表时只需要简单的设置而性能损失最小,这也意味着之后主要版本可以零停机升级!历史上(需要 Postgres 9.4+),这可以通过使用第三方扩展或缓慢的基于触发器的解决方案来实现。对我而言这是 10 最好的功能。

  • 声明分区

以前管理分区的方法通过继承并创建触发器来把插入操作重新路由到正确的表中,这一点很烦人,更不用说性能的影响了。目前支持的是 “range” 和 “list” 分区方案。如果有人在某些数据库引擎中缺少 “哈希” 分区,则可以使用带表达式的 “list” 分区来实现相同的功能。

  • 可用的哈希索引

哈希索引现在是 WAL 记录的,因此是崩溃安全的,并获得了一些性能改进,对于简单的搜索,它们比在更大的数据上的标准 B 树索引快。也支持更大的索引大小。

  • 跨列优化器统计

这样的统计数据需要在一组表的列上手动创建,以指出这些值实际上是以某种方式相互依赖的。这将能够应对计划器认为返回的数据很少(概率的乘积通常会产生非常小的数字)从而导致在大量数据下性能不好的的慢查询问题(例如选择“嵌套循环” join)。

  • 副本上的并行快照

现在可以在 pg\_dump 中使用多个进程(-jobs 标志)来极大地加快备用服务器上的备份。

  • 更好地调整并行处理 worker 的行为

参考 max_parallel_workersmin_parallel_table_scan_size/min_parallel_index_scan_size 参数。我建议增加一点后两者的默认值(8MB、512KB)。

  • 新的内置监控角色,便于工具使用

新的角色 pg_monitorpg_read_all_settingspg_read_all_statspg_stat_scan_tables 能更容易进行各种监控任务 - 以前必须使用超级用户帐户或一些 SECURITY DEFINER 包装函数。

  • 用于更安全的副本生成的临时 (每个会话) 复制槽
  • 用于检查 B 树索引的有效性的一个新的 Contrib 扩展

这两个智能检查发现结构不一致和页面级校验未覆盖的内容。希望不久的将来能更加深入。

  • Psql 查询工具现在支持基本分支(if/elif/else

例如下面的将启用具有特定版本分支(对 pg\_stat* 视图等有不同列名)的单个维护/监视脚本,而不是许多版本特定的脚本。

SELECT :VERSION_NAME = '10.0' AS is_v10 \gset 
\if :is_v10
SELECT 'yippee' AS msg;
\else
SELECT 'time to upgrade!' AS msg;
\endif

这次就这样了!当然有很多其他的东西没有列出,所以对于专职 DBA,我一定会建议你更全面地看发布记录。非常感谢那 300 多为这个版本做出贡献的人!


via: http://www.cybertec.at/best-of-postgresql-10-for-the-dba/

作者:Kaarel Moppel 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

我们在 Sky Betting&Gaming 中使用 Redis 作为共享内存缓存,用于那些需要跨 API 服务器或者 Web 服务器鉴别令牌之类的操作。在 Core Tribe 内,它用来帮助处理日益庞大的登录数量,特别是在繁忙的时候,我们在一分钟内登录数量会超过 20,000 人。这在很大程度上适用于数据存放在大量服务器的情况下(在 SSO 令牌用于 70 台 Apache HTTPD 服务器的情况下)。我们最近着手升级 Redis 服务器,此升级旨在使用 Redis 3.2 提供的原生集群功能。这篇博客希望解释为什么我们要使用集群、我们遇到的问题以及我们的解决方案。

在开始阶段(或至少在升级之前)

我们的传统缓存中每个缓存都包括一对 Redis 服务器,使用 keepalive 确保始终有一个主节点监听 浮动 IP floating IP 地址。当出现问题时,这些服务器对需要很大的精力来进行管理,而故障模式有时是非常各种各样的。有时,只允许读取它所持有的数据,而不允许写入的从属节点却会得到浮动 IP 地址,这种问题是相对容易诊断的,但会让无论哪个程序试图使用该缓存时都很麻烦。

新的应用程序

因此,这种情况下,我们需要构建一个新的应用程序,一个使用 共享内存缓存 shared in-memory cache 的应用程序,但是我们不希望对该缓存进行迂回的故障切换过程。因此,我们的要求是共享的内存缓存,没有单点故障,可以使用尽可能少的人为干预来应对多种不同的故障模式,并且在事件恢复之后也能够在很少的人为干预下恢复,一个额外的要求是提高缓存的安全性,以减少数据泄露的范围(稍后再说)。当时 Redis Sentinel 看起来很有希望,并且有许多程序支持代理 Redis 连接,比如 twemproxy。这会导致还要安装其它很多组件,它应该有效,并且人际交互最少,但它复杂而需要运行大量的服务器和服务,并且相互通信。

将会有大量的应用服务器与 twemproxy 进行通信,这会将它们的调用路由到合适的 Redis 主节点,twemproxy 将从 sentinal 集群获取主节点的信息,它将控制哪台 Redis 实例是主,哪台是从。这个设置是复杂的,而且仍有单点故障,它依赖于 twemproxy 来处理分片,来连接到正确的 Redis 实例。它具有对应用程序透明的优点,所以我们可以在理论上做到将现有的应用程序转移到这个 Redis 配置,而不用改变应用程序。但是我们要从头开始构建一个应用程序,所以迁移应用程序不是一个必需条件。

幸运的是,这个时候,Redis 3.2 出来了,而且内置了原生集群,消除了对单一 sentinel 集群需要。

它有一个更简单的设置,但 twemproxy 不支持 Redis 集群分片,它能为你分片数据,但是如果尝试在与分片不一致的集群中这样做会导致问题。有参考的指南可以使其匹配,但是集群可以自动改变形式,并改变分片的设置方式。它仍然有单点故障。正是在这一点上,我将永远感谢我的一位同事发现了一个 Node.js 的 Redis 的集群发现驱动程序,让我们完全放弃了 twemproxy。

因此,我们能够自动分片数据,故障转移和故障恢复基本上是自动的。应用程序知道哪些节点存在,并且在写入数据时,如果写入错误的节点,集群将自动重定向该写入。这是被选的配置,这让我们共享的内存缓存相当健壮,可以没有干预地应付基本的故障模式。在测试期间,我们的确发现了一些缺陷。复制是在一个接一个节点的基础上进行的,因此如果我们丢失了一个主节点,那么它的从节点会成为一个单点故障,直到死去的节点恢复服务,也只有主节点对集群健康投票,所以如果我们一下失去太多主节点,那么集群无法自我恢复。但这比我们过去的好。

向前进

随着使用集群 Redis 配置的新程序,我们对于老式 Redis 实例的状态变得越来越不适应,但是新程序与现有程序的规模并不相同(超过 30GB 的内存专用于我们最大的老式 Redis 实例数据库)。因此,随着 Redis 集群在底层得到了证实,我们决定迁移老式的 Redis 实例到新的 Redis 集群中。

由于我们有一个原生支持 Redis 集群的 Node.js Redis 驱动程序,因此我们开始将 Node.js 程序迁移到 Redis 集群。但是,如何将数十亿字节的数据从一个地方移动到另一个地方,而不会造成重大问题?特别是考虑到这些数据是认证令牌,所以如果它们错了,我们的终端用户将会被登出。一个选择是要求网站完全下线,将所有内容都指向新的 Redis 群集,并将数据迁移到其中,以希望获得最佳效果。另一个选择是切换到新集群,并强制所有用户再次登录。由于显而易见的原因,这些都不是非常合适的。我们决定采取的替代方法是将数据同时写入老式 Redis 实例和正在替换它的集群,同时随着时间的推移,我们将逐渐更多地向该集群读取。由于数据的有效期有限(令牌在几个小时后到期),这种方法可以导致零停机,并且不会有数据丢失的风险。所以我们这么做了。迁移是成功的。

剩下的就是服务于我们的 PHP 代码(其中还有一个项目是有用的,其它的最终是没必要的)的 Redis 的实例了,我们在这过程中遇到了一个困难,实际上是两个。首先,也是最紧迫的是找到在 PHP 中使用的 Redis 集群发现驱动程序,还要是我们正在使用的 PHP 版本。这被证明是可行的,因为我们升级到了最新版本的 PHP。我们选择的驱动程序不喜欢使用 Redis 的授权方式,因此我们决定使用 Redis 集群作为一个额外的安全步骤 (我告诉你,这将有更多的安全性)。当我们用 Redis 集群替换每个老式 Redis 实例时,修复似乎很直接,将 Redis 授权关闭,这样它将会响应所有的请求。然而,这并不是真的,由于某些原因,Redis 集群不会接受来自 Web 服务器的连接。 Redis 在版本 3 中引入的称为“保护模式”的新安全功能将在 Redis 绑定到任何接口时将停止监听来自外部 IP 地址的连接,并无需配置 Redis 授权密码。这被证明相当容易修复,但让我们保持警惕。

现在?

这就是我们现在的情况。我们已经迁移了我们的一些老式 Redis 实例,并且正在迁移其余的。我们通过这样做解决了我们的一些技术债务,并提高了我们的平台的稳定性。使用 Redis 集群,我们还可以扩展内存数据库并扩展它们。 Redis 是单线程的,所以只要在单个实例中留出更多的内存就会可以得到这么多的增长,而且我们已经紧跟在这个限制后面。我们期待着从新的集群中获得改进的性能,同时也为我们提供了扩展和负载均衡的更多选择。

未来怎么样?

我们解决了一些技术性债务,这使我们的服务更容易支持,更加稳定。但这并不意味着这项工作完成了,Redis 4 似乎有一些我们可能想要研究的功能。而且 Redis 并不是我们使用的唯一软件。我们将继续努力改进平台,缩短处理技术债务的时间,但随着客户群体的扩大,我们力求提供更丰富的服务,我们总是会遇到需要改进的事情。下一个挑战可能与每分钟超过 20,000次 登录到超过 40,000 次甚至更高的扩展有关。


via: http://engineering.skybettingandgaming.com/2017/09/25/redis-2-to-redis-3/

作者:Craig Stewart 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

对于 Secure Shell (SSH) 这样的网络协议来说,其主要职责就是在终端模式下访问一个远程系统。因为 SSH 协议对传输数据进行了加密,所以通过它在远端系统执行命令是安全的。此外,我们还可以在这种加密后的连接上通过创建隧道(端口转发)的方式,来实现两个不同终端间的互联。凭借这种方式,只要我们能通过 SSH 创建连接,就可以绕开防火墙或者端口禁用的限制。

这个话题在网络领域有大量的应用和讨论:

我们在接下来的内容中并不讨论端口转发的细节,而是准备介绍一个如何使用 OpenSSH 来完成 TCP 端口转发的速查表,其中包含了八种常见的场景。有些 SSH 客户端,比如 PuTTY,也允许通过界面配置的方式来实现端口转发。而我们着重关注的是通过 OpenSSH 来实现的的方式。

在下面的例子当中,我们假设环境中的网络划分为外部网络(network1)和内部网络(network2)两部分,并且这两个网络之间,只能在 externo1 与 interno1 之间通过 SSH 连接的方式来互相访问。外部网络的节点之间和内部网络的节点之间是完全联通的。

SSH tunnels: no tunnel

场景 1

在 externo1 节点访问由 interno1 节点提供的 TCP 服务(本地端口转发 / 绑定地址 = localhost / 主机 = localhost )

externo1 节点可以通过 OpenSSH 连接到 interno1 节点,之后我们想通过其访问运行在 5900 端口上的 VNC 服务。

SSH Tunnels: Scenario 1

我们可以通过下面的命令来实现:

externo1 $ ssh -L 7900:localhost:5900 user@interno1 

现在,我们可以在 externo1 节点上确认下 7900 端口是否处于监听状态中:

externo1 $ netstat -ltn
Active Internet connections  (only servers)
Proto Recv-Q  Send-Q  Local Address Foreign Address State      
...
Tcp  0  0  127.0.0.1:7900  0.0.0.0:*  LISTEN  
...

我们只需要在 externo1 节点上执行如下命令即可访问 internal 节点的 VNC 服务:

externo1 $ vncviewer localhost::7900 

注意:在 vncviewer 的 man 手册中并未提及这种修改端口号的方式。在 About VNCViewer configuration of the output TCP port 中可以看到。这也是 the TightVNC vncviewer 所介绍的的。

场景 2

在 externo2 节点上访问由 interno1 节点提供的 TCP 服务(本地端口转发 / 绑定地址 = 0.0.0.0 / 主机 = localhost)

这次的场景跟方案 1 的场景的类似,但是我们这次想从 externo2 节点来连接到 interno1 上的 VNC 服务:

SSH Tunnels: Scenario 2

正确的命令如下:

externo1 $ ssh -L 0.0.0.0:7900:localhost:5900 user@interno1 

看起来跟方案 1 中的命令类似,但是让我们看看 netstat 命令的输出上的区别。7900 端口被绑定到了本地(127.0.0.1),所以只有本地进程可以访问。这次我们将端口关联到了 0.0.0.0,所以系统允许任何 IP 地址的机器访问 7900 这个端口。

externo1 $ netstat -ltn
Active Internet connections  (only servers)
Proto Recv-Q  Send-Q  Local Address Foreign Address State      
...
Tcp  0  0  0.0.0.0:7900  0.0.0.0:*  LISTEN
... 

所以现在在 externo2 节点上,我们可以执行:

externo2 $ vncviewer externo1::7900 

来连接到 interno1 节点上的 VNC 服务。

除了将 IP 指定为 0.0.0.0 之外,我们还可以使用参数 -g(允许远程机器使用本地端口转发),完整命令如下:

externo1 $ ssh -g -L 7900:localhost:5900 user@interno1 

这条命令与前面的命令能实现相同效果:

externo1 $ ssh -L 0.0.0.0:7900:localhost:5900 user@interno1 

换句话说,如果我们想限制只能连接到系统上的某个 IP,可以像下面这样定义:

externo1 $ ssh -L 192.168.24.80:7900:localhost:5900 user@interno1

externo1 $ netstat -ltn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State      
...  
Tcp 0 0 192.168.24.80:7900 0.0.0.0:* LISTEN
...

场景 3

在 interno1 上访问由 externo1 提供的 TCP 服务(远程端口转发 / 绑定地址 = localhost / 主机 = localhost)

在场景 1 中 SSH 服务器与 TCP 服务(VNC)提供者在同一个节点上。现在我们想在 SSH 客户端所在的节点上,提供一个 TCP 服务(VNC)供 SSH 服务端来访问:

SSH Tunnels: Scenario 3

将方案 1 中的命令参数由 -L 替换为 -R

完整命令如下:

externo1 $ ssh -R 7900:localhost:5900 user@interno1 

然后我们就能看到 interno1 节点上对 7900 端口正在监听:

interno1 $ netstat -lnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State      
...  
Tcp 0 0 127.0.0.1:7900 0.0.0.0:* LISTEN
...

现在在 interno1 节点上,我们可以使用如下命令来访问 externo1 上的 VNC 服务:

interno1 $ vncviewer localhost::7900 

场景 4

interno2 使用 externo1 上提供的 TCP 服务(远端端口转发 / 绑定地址 = 0.0.0.0 / 主机 = localhost)

与场景 3 类似,但是现在我们尝试指定允许访问转发端口的 IP(就像场景 2 中做的一样)为 0.0.0.0,这样其他节点也可以访问 VNC 服务:

SSH Tunnels: Scenario 4

正确的命令是:

externo1 $ ssh -R 0.0.0.0:7900:localhost:5900 user@interno1 

但是这里有个重点需要了解,出于安全的原因,如果我们直接执行该命令的话可能不会生效,因为我们需要修改 SSH 服务端的一个参数值 GatewayPorts,它的默认值是:no

GatewayPorts

该参数指定了远程主机是否允许客户端访问转发端口。默认情况下,sshd(8) 只允许本机进程访问转发端口。这是为了阻止其他主机连接到该转发端口。GatewayPorts 参数可用于让 sshd 允许远程转发端口绑定到非回环地址上,从而可以让远程主机访问。当参数值设置为 “no” 的时候只有本机可以访问转发端口;“yes” 则表示允许远程转发端口绑定到通配地址上;或者设置为 “clientspecified” 则表示由客户端来选择哪些主机地址允许访问转发端口。默认值是 “no”。

如果我们没有修改服务器配置的权限,我们将不能使用该方案来进行端口转发。这是因为如果没有其他的限制,用户可以开启一个端口(> 1024)来监听来自外部的请求并转发到 localhost:7900

参照这个案例:netcat ( Debian # 310431: sshd\_config should warn about the GatewayPorts workaround. )

所以我们修改 /etc/ssh/sshd_config,添加如下内容:

GatewayPorts clientspecified 

然后,我们使用如下命令来重载修改后的配置文件(在 Debian 和 Ubuntu 上)。

sudo  /etc/init.d/ssh reload 

我们确认一下现在 interno1 节点上存在 7900 端口的监听程序,监听来自不同 IP 的请求:

interno1 $ netstat -ltn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State      
...    
Tcp 0 0 0.0.0.0:7900 0.0.0.0:* LISTEN
...

然后我们就可以在 interno2 节点上使用 VNC 服务了:

interno2 $ internal vncviewer1::7900

场景 5

在 externo1 上使用由 interno2 提供的 TCP 服务(本地端口转发 / 绑定地址 localhost / 主机 = interno2 )

SSH Tunnels: Scenario 5

在这种场景下我们使用如下命令:

externo1 $ ssh -L 7900:interno2:5900 user@interno1

然后我们就能在 externo1 节点上,通过执行如下命令来使用 VNC 服务了:

externo1 $ vncviewer localhost::7900

场景 6

在 interno1 上使用由 externo2 提供的 TCP 服务(远程端口转发 / 绑定地址 = localhost / host = externo2)

SSH Tunnels: Scenario 6

在这种场景下,我们使用如下命令:

externo1 $ ssh -R 7900:externo2:5900 user@interno1 

然后我们可以在 interno1 上通过执行如下命令来访问 VNC 服务:

interno1 $ vncviewer localhost::7900 

场景 7

在 externo2 上使用由 interno2 提供的 TCP 服务(本地端口转发 / 绑定地址 = 0.0.0.0 / 主机 = interno2)

SSH Tunnels: Scenario 7

本场景下,我们使用如下命令:

externo1 $ ssh -L 0.0.0.0:7900:interno2:5900 user@interno1 

或者:

externo1 $ ssh -g -L 7900:interno2:5900 user@interno1 

然后我们就可以在 externo2 上执行如下命令来访问 vnc 服务:

externo2 $ vncviewer externo1::7900 

场景 8

在 interno2 上使用由 externo2 提供的 TCP 服务(远程端口转发 / 绑定地址 = 0.0.0.0 / 主机 = externo2)

SSH Tunnels: Scenario 8

本场景下我们使用如下命令:

externo1 $ ssh -R 0.0.0.0:7900:externo2:5900 user@interno1 

SSH 服务器需要配置为:

GatewayPorts clientspecified 

就像我们在场景 4 中讲过的那样。

然后我们可以在 interno2 节点上执行如下命令来访问 VNC 服务:

interno2 $ internal vncviewer1::7900 

如果我们需要一次性的创建多个隧道,使用配置文件的方式替代一个可能很长的命令是一个更好的选择。假设我们只能通过 SSH 的方式访问某个特定网络,同时又需要创建多个隧道来访问该网络内不同服务器上的服务,比如 VNC 或者 远程桌面。此时只需要创建一个如下的配置文件 $HOME/redirects 即可(在 SOCKS 服务器 上)。

# SOCKS server
DynamicForward 1080

# SSH redirects
LocalForward 2221 serverlinux1: 22
LocalForward 2222 serverlinux2: 22
LocalForward 2223 172.16.23.45:22
LocalForward 2224 172.16.23.48:22

# RDP redirects for Windows systems
LocalForward 3391 serverwindows1: 3389
LocalForward 3392 serverwindows2: 3389

# VNC redirects for systems with "vncserver"
LocalForward 5902 serverlinux1: 5901
LocalForward 5903 172.16.23.45:5901

然后我们只需要执行如下命令:

externo1 $ ssh -F $HOME/redirects user@interno1 

via: https://wesharethis.com/2017/07/creating-tcp-ip-port-forwarding-tunnels-ssh-8-possible-scenarios-using-openssh/

作者:Ahmad 译者:toutoudnf 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出