记一次在 AWS 网络出故障的时候让自己的线上服务提前”恢复”

嗯, 首先声明, 这个方法不具备普适性, 甚至几乎完全是一个运气问题, 不过总觉得这么神奇的事情还是写一下吧, 于是才有了这篇 blog.

22:08 A 服务器突然离线, 访问分配的 Elastic IP 不通.
22:15 发现我在同机房的另一台 AWS (B) 在线, 遂登陆访问 A 的 AWS 私有 IP – 通!
22:20 用 B 开 ssh -D, 配合 tsocks 登陆 A 的 AWS 私有 IP, 检查服务器状况良好. 抓包确认包可以正常从 Elastic IP 出去, 但是回不来. 确认是 AWS 的错.
22:23 登陆 Cloudflare 修改服务的解析到 B. (Automatic 的 DNS 缓存时间居然只有 30 秒, 怒赞)
22:32 AWS 在其 status 页面宣布 “We are investigating network connectivity issues for instances in the US-EAST-1 Region.”
22:35 在 B 上用 nginx 架设反向代理, 并拷贝本地备份的 A 的 SSL 证书到 B. 服务恢复在线.
23:02 A 的原 Elastic IP 恢复正常访问.

嗯, 是时候折腾些自动化工具来做反代了, 有时候出其不意的能发挥点作用. 这次我的 downtime 比 AWS 的 downtime 短了近一倍, 然而如果我架设反代的速度再快点, 还能有更大提升的说(
Continue reading 记一次在 AWS 网络出故障的时候让自己的线上服务提前”恢复”

[译] 如何防止丢失任何 bash 历史命令?

原文链接: http://mywiki.wooledge.org/BashFAQ/088
译者: Felix Yan

注: 这个方法是为了让你保存一个用户的完整命令记录; 它不是用来对用户输入的命令做安全审计的 – 对这个用途, 请阅读提升 bash 安全-防止命令历史被移除 (英文)

默认情况下, bash 只在退出的时候更新命令历史, 而且这个”更新”是用新版直接覆盖旧版. 这会使你无法保持一份完整的命令历史记录, 原因有两个:

  • 如果一个用户登录多次, 这种覆盖的机制会使得只有最后一个退出的 bash 能保存它的历史记录. (一个登录的用户打开多个终端模拟器, 或者使用 screen/tmux 等工具启动多个 bash 等也在此列 – 译者注)
  • 如果你的 bash 异常退出了 – 比如网络故障, 防火墙更改, 或者它的进程被杀掉了 – 会话中所有的历史记录都会丢失.

为了解决前一个问题, 我们设置命令行选项 histappend 来采用”追加”的方式写入新的命令历史记录, 并保证了多次登录不会覆盖彼此的历史记录.

为了使得命令历史记录不因为 bash 异常退出而丢失, 我们需要保证每次命令之行后, 对应命令的历史记录就被写入. 我们可以用 bash 内置的 history -a 命令来强制立刻写入命令历史记录, 而且我们可以将这个命令添加到 PROMPT_COMMAND 环境变量中, 使得这个过程自动化. 这个环境变量会在每次新的命令提示符出现前被执行一次, 因此会在每个命令执行后被执行.
Continue reading [译] 如何防止丢失任何 bash 历史命令?