Linux

Nginx 配合 CloudFlare 获取真实 IP 并限制访问

by Orange

在最近一次网站部署中，考虑到安全因素，希望将源站完全隐藏在 CF 后，只允许 CF 访问，并尽可能的减少信息泄漏。

获取真实客户端 IP

由于经过 CloudFlare 代理后，Nginx 看到的 remote ip 其实是 CF 的 IP 地址。因此需要通过 Nginx 的 ngx_http_realip_module，还原出真实的客户端 IP。这一步在 CloudFlare 有详细的文档说明。

简单来说，当发现请求 IP 为 CF 的 IP 段时，读取 CF-Connecting-IP 头，并将其中的 IP 设置为客户端 IP。CF 的 IP 段可以通过 API 获取。以下是一个脚本可以生成相关的配置：

#!/bin/bash

# 脚本：获取 Cloudflare IP 列表并生成 Nginx 配置

# 输出文件
IP_CONFIG_FILE="cf_ips.conf"

# 清空输出文件
> "$IP_CONFIG_FILE"

# Cloudflare IP 列表 API 端点
CLOUDFLARE_API_URL="https://api.cloudflare.com/client/v4/ips"

# 生成 set_real_ip_from 配置
echo "# Cloudflare IPv4 IPs" >> "$IP_CONFIG_FILE"
curl -s "$CLOUDFLARE_API_URL" | jq -r '.result.ipv4_cidrs[]' | while read -r ip; do
    echo "set_real_ip_from $ip;" >> "$IP_CONFIG_FILE"
done

echo -e "\n# Cloudflare IPv6 IPs" >> "$IP_CONFIG_FILE"
curl -s "$CLOUDFLARE_API_URL" | jq -r '.result.ipv6_cidrs[]' | while read -r ip; do
    echo "set_real_ip_from $ip;" >> "$IP_CONFIG_FILE"
done

# 添加 real_ip_header 配置
echo -e "\n# Set real IP header" >> "$IP_CONFIG_FILE"
echo "real_ip_header CF-Connecting-IP;" >> "$IP_CONFIG_FILE"

脚本运行后会生成 cf_ips.conf 文件，内含 set_real_ip_from 和 real_ip_header 配置，在 http 段 include 该文件，即可自动为所有 server 自动设置真实客户端 IP。

限制仅 CloudFlare IP 访问

解决了真实客户端 IP 的问题后，接下来就是如何做到仅限 CF IP 访问。由于该 Nginx 托管了多个 server，因此并不希望直接从防火墙层面拒绝所有非 CF IP 访问。那么从 Nginx 侧，第一时间想到的就是用 ngx_http_access_module 的方式，仅放过 CF IP 段：

# Cloudflare IPv4 Allow
allow 173.245.48.0/20;
allow 103.21.244.0/22;
allow 103.22.200.0/22;
allow 103.31.4.0/22;
allow 141.101.64.0/18;
allow 108.162.192.0/18;
allow 190.93.240.0/20;
allow 188.114.96.0/20;
allow 197.234.240.0/22;
allow 198.41.128.0/17;
allow 162.158.0.0/15;
allow 104.16.0.0/13;
allow 104.24.0.0/14;
allow 172.64.0.0/13;
allow 131.0.72.0/22;

# Cloudflare IPv6 Allow
allow 2400:cb00::/32;
allow 2606:4700::/32;
allow 2803:f800::/32;
allow 2405:b500::/32;
allow 2405:8100::/32;
allow 2a06:98c0::/29;
allow 2c0f:f248::/32;

# Default deny
deny all;

但是添加了这段配置后，发现不论是否通过 CF 访问，所有请求均会被拦截，返回 403。搜索相关文章1后发现，这是因为 ngx_http_realip_module 已经先执行完毕了，此时 ngx_http_access_module 拿到的已经是被修改了的真实客户端 IP，自然无法通过检测，被拒绝访问。

为了解决该问题，我们需要使用其他手段来进行访问控制。查阅相关资料后发现，ngx_http_geo_module 是个非常好的选择。相关配置如下：

geo $realip_remote_addr $is_cf {
  default 0;
  # Cloudflare IPv4 Allow
  173.245.48.0/20 1;
  103.21.244.0/22 1;
  103.22.200.0/22 1;
  103.31.4.0/22 1;
  141.101.64.0/18 1;
  108.162.192.0/18 1;
  190.93.240.0/20 1;
  188.114.96.0/20 1;
  197.234.240.0/22 1;
  198.41.128.0/17 1;
  162.158.0.0/15 1;
  104.16.0.0/13 1;
  104.24.0.0/14 1;
  172.64.0.0/13 1;
  131.0.72.0/22 1;

  # Cloudflare IPv6 Allow
  2400:cb00::/32 1;
  2606:4700::/32 1;
  2803:f800::/32 1;
  2405:b500::/32 1;
  2405:8100::/32 1;
  2a06:98c0::/29 1;
  2c0f:f248::/32 1;
}

其中，$realip_remote_addr 是 ngx_http_realip_module 提供的变量，存储了原始的客户端地址。通过 CF 访问的情况下，这个变量存储的就是原始的 CF 地址。$is_cf 是用于储存中间结果的变量。如果原始客户端地址在 CF IP 段，则会被设置为 1，否则为 0。

有了这个变量之后，我们就可以使用 ngx_http_rewrite_module 来进行判断，并拒绝访问。在需要的地方增加如下代码：

if ($is_cf = 0) {
    return 444;
}

即可拒绝掉所有非 CF 访问的情况。

使用 OpenResty

如果在使用 OpenResty，那么有更简单的方式2可以做这个事情。借助 access_by_lua_block，我们可以直接在 lua 里访问相关变量进行判断，并拒绝非 CF 的访问：

access_by_lua_block {
    if ngx.var.remote_addr == ngx.var.realip_remote_addr then
            return ngx.exit(ngx.HTTP_FORBIDDEN)
    end
}

原理其实也很简单，如果 ngx.var.remote_addr 和 ngx.var.realip_remote_addr 是相同的，则证明 ngx_http_realip_module 没有起作用，那么说明原始访问 IP 一定不在 CF IP 段内。

注意事项

  1. 有条件的情况下（即 Nginx 所有 server 都托管在 CF），应使用防火墙直接拒绝所有非 CF IP 的 TCP 链接
  2. 由于 if 指令只能使用在 server, location 使用，因此该方法在多个 server 内，需要重复配置
  3. 由于 ssl_reject_handshake 无法在 if 内使用，因此如果攻击者猜对了 server_name，那么证书信息依然会泄漏，存在被探测到源站的可能

参考文档

  1. https://serverfault.com/questions/601339/how-do-i-deny-all-requests-not-from-cloudflare/826428#826428 ↩︎
  2. https://stackoverflow.com/questions/39176931/nginx-allowdeny-realip-remote-addr/39183303#39183303 ↩︎

QNAP 新版 License Center 校验流程逆向

by Orange

最近新添置了两个支持 ONVIF 协议的摄像头，想使用 QNAP 的 QVR 进行录像。但是打开 QVR 发现，只能添加两个通道，后续新的通道需要按年付费解锁。依稀记得原先是有 8 个免费通道可用的，于是打开官方文档，发现：

系统软件授权
QTSQVR Pro自带 8 通道
QTSQVR Elite自带 2 通道
QuTS heroQVR Elite自带 2 通道

原来官方提供的 8 通道 QVR Pro 只支持 QTS 系统，不支持基于 ZFS 的 QuTS hero 系统。既然官方不支持，那只能自己动手了。

TL; DR

  1. GPT 太好用了，大大提升逆向效率
  2. 新版校验用的 Public Key 经过简单的凯撒密码加密后打包在 libqlicense.so 中
  3. LIF 文件的 floating 相关字段需要干掉，否则会联机校验

激活流程

在研究的过程中，发现已有前人详细分析了激活流程的各个步骤，分析了各个文件的存储、编码、加密、验证格式，并编写了相关脚本和代码。具体文章在这里，此处不多做赘述：

https://jxcn.org/2022/03/qnap-license

尝试动手

参考文章，尝试在 NAS 上进行操作。结果发现，找不到文章中提及的 qlicense_public_key.pem 文件，全盘搜索后发现依然找不到该文件。查看文章评论发现，似乎官方在 23 年左右修改了一次校验逻辑，去掉了该文件。所有 23 年之后发布的版本，都无法使用替换 key 文件的方式进行激活。

重新分析

虽然官方修改了相关逻辑，但是有前人经验参考，还是很快发现了关键所在。

先用 IDA 打开 qlicense_tool ，找到离线激活的处理函数，发现对输入进行简单处理后直接调用了 qcloud_license_offline_activate 函数，位于 libqlicense.so 动态链接库中。这个函数在几层调用之后，最终调用了 qcloud_license_internal_verify 函数，对 LIF 文件的签名进行了计算。

由于静态分析不太容易理清逻辑，于是上 GDB 准备直接调试。找了下发现 MyQNAP Repo 里有编译好的 GDB，但是安装却失败了。研究了下发现是作者把 X86 和 X41 的链接搞反了。X86 下载到的包是 X41 的，导致安装失败。于是手动下载了正确的包之后安装，一切顺利。

通过 gdb 调试发现，qcloud_license_internal_verify 函数的第一个入参就是校验用的 Public Key，打出来长这样：

-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEDJcPoMIFyYDlhTUzNSeT/+3ZKcByILoI
Fw8mLv07Hpy2I5qgAGQu66vF3VUjFKgpDDFKVER9jwjjmXUOpoCXX4ynvFUpEM25
ULJE86Z6WjcLqyG03Mv6d3GPYNl/cJYt
-----END PUBLIC KEY-----

通过 hook fopen 函数，想找到这个 key 存储在哪个文件，但是发现并没有结果。于是想到，这段 key 可能被打进了 so 文件本身，于是通过 Strings 搜索，但是依然没有找到相关字符串。

一筹莫展之际，在调用链路上乱点，突然注意到这样一段奇怪的代码（IDA 还原得出）：

    while ( 1 )
    {
      result[v3] = (v1[v3] + 95) % 128;
      if ( ++v3 == 359 )
        break;
      result = (_BYTE *)*a1;
    }

多看两眼之后意识到，这就是凯撒密码。（虽然凯撒密码现在看来其实更应该算是编码而非加密，但是考虑到确实有相关定义，因此后续均表述为加密和解密。）也就是说，之所以在 Strings 内找不到相关字符串，是因为写入的是通过凯撒密码加密后的字符串。于是把这段丢给 GPT，让它写个加密和解密的代码：

# -*- coding: utf-8 -*-

def decode(input_string):
    result = []
    for char in input_string:
        # 将每个字符的 ASCII 值加 95，然后对 128 取模
        encoded_char = (ord(char) + 95) % 128
        result.append(chr(encoded_char))
    return ''.join(result)

def encode(encoded_string):
    result = []
    for char in encoded_string:
        # 逆向解码：恢复原始字符
        decoded_char = (ord(char) - 95) % 128
        result.append(chr(decoded_char))
    return ''.join(result)

original_text = """-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEDJcPoMIFyYDlhTUzNSeT/+3ZKcByILoI
Fw8mLv07Hpy2I5qgAGQu66vF3VUjFKgpDDFKVER9jwjjmXUOpoCXX4ynvFUpEM25
ULJE86Z6WjcLqyG03Mv6d3GPYNl/cJYt
-----END PUBLIC KEY-----"""
encoded_text = encode(original_text)
decoded_text = decode(encoded_text)

print("Original:", original_text)
print("Encoded:", encoded_text)
print("Decoded:", decoded_text)

跑了一下，得到实际存储的字符串：

NNNNNcfhjoAqvcmjdAlfzNNNNN+niz\u0018fbzil\u0010{j\u001b\u000bQdbrzglUffbdjez\bbfek\u0004q\u0010njg\u001aze\r\tuv\u001bot\u0006uPLT{l\u0004c\u001ajm\u0010j+g\u0018Y\u000em\u0017QXi\u0011\u001aSjV\u0012\bbhr\u0016WW\u0017gTwv\u000bgl\b\u0011eeglwfsZ\u000b\u0018\u000b\u000b\u000eyvp\u0011\u0010dyyU\u001a\u000f\u0017gv\u0011fnSV+vmkfYW{Wx\u000b\u0004m\u0012\u001ahQTn\u0017W\u0005Thqzo\rP\u0004kz\u0015+NNNNNfoeAqvcmjdAlfzNNNNN

由于开头和结尾的 ----- 会被加密为 NNNNN 因此直接在 Strings 中搜索，顺利定位到相关资源，位于 .rodata 段 38B40 的位置，长度 212。

接下来操作就简单了，生成一对新的 key 之后，直接替换指定位置即可。注意，由于长度是写死在代码里的，因此二者必须等长，否则可能会出现无法预料的错误。

再丢给 GPT 写个十六进制替换的脚本：

# -*- coding: utf-8 -*-

import binascii

def hex_to_bytes(hex_str):
    """将16进制字符串转换为字节数据。"""
    return binascii.unhexlify(hex_str)

def patch_file(file_path, search_hex, replace_hex):
    # 将16进制模式转换为字节数据
    search_bytes = hex_to_bytes(search_hex)
    replace_bytes = hex_to_bytes(replace_hex)
    
    # 检查替换块的长度是否匹配
    if len(search_bytes) != len(replace_bytes):
        raise ValueError("Length mismatch! 搜索模式和替换内容长度必须相同！")

    # 读取文件内容
    with open(file_path, "rb") as f:
        data = f.read()

    # 查找并替换内容
    patched_data = data.replace(search_bytes, replace_bytes)

    # 如果没有找到匹配的内容
    if data == patched_data:
        print("No Match. 没有找到匹配的内容。")
    else:
        # 将修改后的内容写回文件
        with open(file_path, "wb") as f:
            f.write(patched_data)
        print("Patch success. 文件已成功更新。")

# 使用示例
file_path = "libqlicense.so"           # 需要打补丁的文件路径
old_hex = "4e4e4e4e4e6366686a6f417176636d6a64416c667a4e4e4e4e4e2b6e697a1866627a696c107b6a1b0b516462727a676c55666662646a657a086266656b0471106e6a671a7a650d0975761b6f740675504c547b6c04631a6a6d106a2b6718590e6d17515869111a536a56120862687216575717675477760b676c08116565676c7766735a0b180b0b0e7976701110647979551a0f17677611666e53562b766d6b6659577b57780b046d121a6851546e1757055468717a6f0d50046b7a152b4e4e4e4e4e666f65417176636d6a64416c667a4e4e4e4e4e"              # 要搜索的16进制字符串
new_hex = "4e4e4e4e4e6366686a6f417176636d6a64416c667a4e4e4e4e4exxx4e4e4e4e4e666f65417176636d6a64416c667a4e4e4e4e4e"             # 替换为的16进制字符串

# 执行替换操作
patch_file(file_path, old_hex, new_hex)

这里使用 Hex Encoding 的原因是加密后的字符串存在一些非 ASCII 字符。

替换后，用原作者的相关脚本和工具，生成了一个 LIF，尝试使用 qlicense_tool 激活。此时发现，激活死活失败，但是调试发现 verify 实际已经过了。研究了好久之后，发现是 Console Management 工具导致的。由于 qlicense_tool 在激活过程中会运行被激活服务的脚本检测 License 正确性，而 Console Management 拦截了相关命令，导致返回包不是合法的 json，导致失败。在系统设置内关闭 Console Management 后，激活成功。

检测报错

本以为到此激活就成功了。结果打开许可证中心之后，发现许可证无效了。查阅相关日志，发现许可证中心发送了一个 POST 请求到 https://license.myqnapcloud.io/v1.1/license/device/installed ，然后报错许可不属于该设备，然后将许可改为失效。

阅读原作者相关文章，结合代码，发现是因为原作者是为了 QuTS Cloud 设计的代码，由于 Cloud 版没有离线激活功能，所以会定期刷新 Token，这里一刷新就发现许可有问题了。于是修改代码，将 LIF 内的 floating 相关字段全部干掉。包括：

FloatingUUID
FloatingToken
LicenseCheckPeriod

重新生成 LIF 文件，再次激活，已经不会向 myqnapcloud 验证激活信息了。

安全的调试容器内的进程

by Orange

通常来说，使用 gdb 等工具调试测试或生产环境的进程，是非常好的查找 Bug 的方式。但是当我们步入容器时代后，使用 gdb 工具却会遇到一些麻烦。

当我们进入容器内，尝试使用 gdb attach 的方式开始调试已运行的进程时，会得到这样的报错：

Attaching to process 123
ptrace: Operation not permitted.

通过简单的搜索我们可以发现，这是因为容器内为了安全，默认没有给 SYS_PTRACE 权限的原因。于是，很多教程告诉我们，用这个命令启动容器解决这个问题：

docker run xxx --cap-add=SYS_PTRACE

然而，在生产环境授予容器 SYS_PTRACE 权限是很危险的，有可能造成容器逃逸。因此，如果需要启用该权限，建议慎重考虑。

那么，有没有办法避开这个权限呢？由于容器本身其实就是主机上的一个进程，所以我们自然会想到，能否直接从主机找到对应的进程，然后在主机上执行 gdb attach 呢？

事实上我们可以这样操作，但是由于容器内的二进制文件在主机上并没有，所以 gdb attach 之后会报 No such file，并不能正常工作。就算我们把二进制拷贝出来，放在对应的位置上，gdb 还是会有 warning：

warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable.  Connect to gdbserver inside the container.

这个 warning 就是告诉我们，正在运行的 gdb 进程的 PID namespace 与想要调试的进程的不同，这会导致我们的线程列表等数据出现偏差，可能会影响调试。

考虑到容器的实现原理就是在不同的 namespace 中运行程序，因此如果我们能以容器进程的 namespace 启动一个调试器，那就能解决这个问题了。经过一番搜索，发现 Linux 提供了一个叫 nsenter 的工具来做这件事。我们只需要这样操作：

nsenter -m -u -i -n -p --target ${PID} bash

就可以启动一个跟容器内进程共用同一个 namespace 的 bash，并且该 bash 并没有 SYS_PTRACE 权限的限制，可以非常方便的使用 gdb 了。

深入理解 System.currentTimeMillis() 与时区

by Orange

今天在解答同事对于 Unix Timestamp 的时区问题的疑问时，看到了这篇文章：

深入理解System.currentTimeMillis()

https://coderdeepwater.cn/2020/12/29/java_source_code/currentTimeMillis/

通过阅读发现，虽然该文章对于这个函数调用的原理解释的非常好，但是却在开头处犯了一个致命的错误，误导了我的同事。在这篇文章中，作者说：

深入理解System.currentTimeMillis()

System.currentTimeMills()的返回值取决于Java运行时系统的本地时区!千万不要忘记这一点!
同一时刻,在英国和中国的两个人同时用System.currentTimeMills()获取当前系统时间,其返回值不是一样的,除非手动将操作系统的时区设置成同一个时区(英国使用UTC+0,而中国使用UTC+8,中国比英国快8个小时).

这个观点是完全错误的，正因为这里的错误误导了我的同事，走入了错误的排查方向。

首先说结论：

  1. System.currentTimeMillis() 的返回值与系统时区无关。在一台时区和时间皆设置正确的机器上，这个函数的返回值总是当前时间与 UTC 0 时的 1970年1月1日 0时0分0秒即 1970-01-01 00:00:00 UTC 的差值
  2. 同一时刻，在地球上任意地点的两个人在时区和时间皆设置正确的机器上同时用 System.currentTimeMills() 获取当前系统时间，其返回值一定一样，与时区无关

首先明确几个概念：

  1. 时间：是一个客观存在的物理量，是物质运动变化的表现
  2. 时间单位：人为了方便对时间进行计量，人为定义了年、月、日、时、分、秒、毫秒等一系列时间单位
  3. 公历日期：人为规定的纪年体系，用来记录准确的时间
  4. 时区：由于地球自转的存在，地球上各个地区的日升日落时间并不一致。因此为了使用方便，人为将地球划分成了 24 个时区，每两个相邻时区间的时间表示相差 1 小时
  5. Unix 时间戳：人为规定的用来描述一个确切时间点的系统。以 1970-01-01 00:00:00 UTC 为基点，计算当前时间与基点的秒数差，不考虑闰秒

从这几个概念中，我们可以知道，Unix 时间戳是用于精确描述一个确定的时间点，具体的方式是计算两个时间点之间的秒数差。由于我们的宇宙只有单时间线，所以计算两个确定的时间点之间的秒数差，在地球上任何地方的时间都是一致的。因此我们可以知道，在一个确定的时间点上，地球上所有人计算得到的当前的 Unix 时间戳，都应当是一致的。

那么，为什么还有人遇到不同时区获取到的时间戳不一致的问题呢？这就要说到实际使用中对时间的展示方式了。

一个简单的例子，如果我说现在是北京时间 2020年01月01日 08时00分00秒，那么这可以表示一个准确的时刻。对于同一个时刻，我还可以说，现在是格林威治时间 2020年01月01日 00时00分00秒。这两个句子实际上表达的是同一个时刻。

但是，如果我只说现在是 2020年01月01日 00时00分00秒，那么不能表示一个准确的时刻。因为在句话里，我没有说明时区信息，导致缺失了定位到准确时刻的必要条件。

因此我们可以发现，我们日常说话时的表述，其实都是不精确的。那么在程序员的世界里，我们最容易犯的错误，也跟这个类似。

当我们查看一个服务器的时间信息的时候，大多数人不会关心时区信息。假设现在有一台 UTC 0 时区的服务器，很多人拿到后，在检查服务器时间时，第一反应是这个服务器的时间不对，因为桌面上的时钟是 2020年01月01日 08时00分00秒，而机器告诉我的是 2020年1月1日 00时00分00秒，晚了 8 小时。于是，使用 date -s "2020/01/01 08:00:00" 一把梭，再看机器的时间，完美！

那么这时候，如果我用 System.currentTimeMills()来获取时间戳，得到的是什么呢？得到的当然是 1577865600000，代表北京时间 2020年01月01日 16时00分00秒。因为机器本身运行在 0 时区，对于机器来说，现在是 0 时区的 8 点，那换算到 +8 的北京时区，自然是 16 点。

这也就是前面为何一直强调时区和时间皆设置正确的原因。刚说的案例就是典型的时间与时区设置不匹配。机器的时区是 0 时区的，但是用户设置进去的时间却是 +8 时区的。在这种情况下，System.currentTimeMills()自然获取不到正确的值。

因此，我们在修改机器的系统时间时，一定要带上时区信息。如：date -s "2020/01/01 08:00:00 +8" 。这样就可以准确的告诉系统我们想要设置的时刻，避免因为自动的时区转换导致调错机器的时间。

Linux 下查看指定进程环境变量信息

by Orange

Linux 会为每个进程生成一个目录，保存了进程相关的大量信息。具体位置在：

/proc/${pid}

一般有如下文件：

total 0
-rw-r--r-- 1 root root 0 Dec 31 00:00 autogroup
-r-------- 1 root root 0 Dec 31 00:00 auxv
-r--r--r-- 1 root root 0 Dec 31 00:00 cgroup
--w------- 1 root root 0 Dec 31 00:00 clear_refs
-r--r--r-- 1 root root 0 Dec 31 00:00 cmdline
-rw-r--r-- 1 root root 0 Dec 31 00:00 comm
-rw-r--r-- 1 root root 0 Dec 31 00:00 coredump_filter
-r--r--r-- 1 root root 0 Dec 31 00:00 cpuset
lrwxrwxrwx 1 root root 0 Dec 31 00:00 cwd -> /root
-r-------- 1 root root 0 Dec 31 00:00 environ
lrwxrwxrwx 1 root root 0 Dec 31 00:00 exe -> /usr/bin/bash
dr-x------ 2 root root 0 Dec 31 00:00 fd
dr-x------ 2 root root 0 Dec 31 00:00 fdinfo
-r--r--r-- 1 root root 0 Dec 31 00:00 hostinfo
-r-------- 1 root root 0 Dec 31 00:00 io
-r--r--r-- 1 root root 0 Dec 31 00:00 latency
-r--r--r-- 1 root root 0 Dec 31 00:00 limits
-rw-r--r-- 1 root root 0 Dec 31 00:00 loginuid
-r--r--r-- 1 root root 0 Dec 31 00:00 maps
-rw------- 1 root root 0 Dec 31 00:00 mem
-r--r--r-- 1 root root 0 Dec 31 00:00 mountinfo
-r--r--r-- 1 root root 0 Dec 31 00:00 mounts
-r-------- 1 root root 0 Dec 31 00:00 mountstats
dr-xr-xr-x 7 root root 0 Dec 31 00:00 net
dr-x--x--x 2 root root 0 Dec 31 00:00 ns
-r--r--r-- 1 root root 0 Dec 31 00:00 numa_maps
-rw-r--r-- 1 root root 0 Dec 31 00:00 oom_adj
-r--r--r-- 1 root root 0 Dec 31 00:00 oom_score
-rw-r--r-- 1 root root 0 Dec 31 00:00 oom_score_adj
-r--r--r-- 1 root root 0 Dec 31 00:00 pagemap
-r--r--r-- 1 root root 0 Dec 31 00:00 personality
lrwxrwxrwx 1 root root 0 Dec 31 00:00 root -> /
-rw-r--r-- 1 root root 0 Dec 31 00:00 sched
-r--r--r-- 1 root root 0 Dec 31 00:00 sessionid
-r--r--r-- 1 root root 0 Dec 31 00:00 smaps
-r--r--r-- 1 root root 0 Dec 31 00:00 stack
-r--r--r-- 1 root root 0 Dec 31 00:00 stat
-r--r--r-- 1 root root 0 Dec 31 00:00 statm
-r--r--r-- 1 root root 0 Dec 31 00:00 status
-r--r--r-- 1 root root 0 Dec 31 00:00 syscall
dr-xr-xr-x 3 root root 0 Dec 31 00:00 task
-r--r--r-- 1 root root 0 Dec 31 00:00 wchan

其中的 exe 指向进程的可执行文件，cwd 指向进程的工作目录，environ 就是进程所看到的环境变量的信息了。

直接 cat 这个文件，可以看到所有的变量信息。但是这里看到的变量都是挤在一起的，没有换行。

使用 vim 打开这个文件，可以看到实际上文件中是有符号分隔的，在 vim 里展示为 ^@ 。经过搜索，该符号代表的其实是 \0，也就是字符串结尾的意思。于是使用 tr 命令稍作处理，即可得到可读性强的换行分隔的环境变量信息：

tr '\0' '\n'< /proc/${pid}/environ

dd 常用命令汇总

by Orange

生成指定大小的文件

dd if=/dev/urandom of=sample.txt bs=1G count=1
dd if=/dev/urandom of=sample.txt bs=64M count=16

dd if=/dev/random of=sample.txt bs=1G count=1
dd if=/dev/random of=sample.txt bs=64M count=16

测试磁盘的读写速度

一般常用的能查到的测试磁盘读写速度的命令是下面几个：

dd bs=1M count=256 if=/dev/zero of=test
dd bs=1M count=256 if=/dev/zero of=test; sync
dd bs=1M count=256 if=/dev/zero of=test conv=fdatasync
dd bs=1M count=256 if=/dev/zero of=test oflag=dsync

但是实际上，这几个的效果并不完全相同：

  1. dd bs=1M count=256 if=/dev/zero of=test
    The default behaviour of dd is to not “sync” (i.e. not ask the OS to completely write the data to disk before dd exiting). The above command will just commit your 256 MB of data into a RAM buffer (write cache) – this will be really fast and it will show you the hugely inflated benchmark result right away. However, the server in the background is still busy, continuing to write out data from the RAM cache to disk.
    dd 的默认行为是不做任何“同步”操作（也就是说，不要求操作系统在 dd 终止前完整的将数据写入磁盘。）上面那个命令只会给你分配 256M 的 RAM 缓存（写缓存）- 这个操作是非常快的，会告诉你非常夸张的测试觉果。但是实际上，服务器本身还在后台繁忙的进行写入操作，来将你刚刚写入 RAM 缓存的数据同步到磁盘。

    # dd bs=1M count=256 if=/dev/zero of=test
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 0.217855 s, 1.2 GB/s
  2. dd bs=1M count=256 if=/dev/zero of=test; sync
    Absolutely identical to the previous case, as anyone who understands how *nix shell works should surely know that adding a ; sync does not affect the operation of previous command in any way, because it is executed independently, after the first command completes. So your (inflated) MB/sec value is already printed on screen while that sync is only preparing to be executed.
    跟上一个命令完全相同。任何知道 *nix shell 如何运作的人都一定知道只是加一个 ; sync 并不会影响签名一条命令，因为这两条命令是完全分开执行的，添加的 sync 是在 dd 执行结束之后才会执行的。所以当你看到夸张的 MB/s 的值的时候，sync 命令才刚刚开始准备执行。

    # dd bs=1M count=256 if=/dev/zero of=test; sync
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 0.225096 s, 1.2 GB/s
(Waiting for sync)
#
  3. dd bs=1M count=256 if=/dev/zero of=test conv=fdatasync
    This tells dd to require a complete “sync” once, right before it exits. So it commits the whole 256 MB of data, then tells the operating system: “OK, now ensure this is completely on disk”, only then measures the total time it took to do all that and calculates the benchmark result.
    这条指令告诉 dd 在退出之前必须要等待“同步”结束。所以该命令先是创建了 256M 的数据，然后告诉系统：“现在确认这些数据已经写到了磁盘上”，然后才开始停止计时并计算测试的结果。

    # dd bs=1M count=256 if=/dev/zero of=test conv=fdatasync
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 1.54606 s, 174 MB/s
  4. dd bs=1M count=256 if=/dev/zero of=test oflag=dsync
    Here dd will ask for completely synchronous output to disk, i.e. ensure that its write requests don’t even return until the submitted data is on disk. In the above example, this will mean sync’ing once per megabyte, or 256 times in total. It will be the slowest mode, as the write cache is basically unused at all in this case.
    这条命令 dd 会要求完全同步写入磁盘，也就是说，任何一个写入请求在数据完全保存到磁盘之前都不会返回。在上面这条命令里，这代表 dd 将会每 1MB 同步一次，或者说一共要同步256次。所以这是最慢模式，因为这种情况下基本上完全没有使用缓存。

    # dd bs=1M count=256 if=/dev/zero of=test oflag=dsync
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 2.40251 s, 112 MB/s

    当然有时候连续执行第三条和第四条命令，第四条并不比第三条慢。这可能是由于其他应用的 IO 占用导致的。

所以，一般情况下推荐使用第三条命令来进行测试，尽可能快的得到尽可能准确的结果。

原文地址：https://romanrm.net/dd-benchmark

CentOS Bash Proxy 设置

by Orange

今天在服务器上做一个 Bash 代理的配置，想要将某些地址去除代理，于是搜了一下，基本上答案都是：

export no_proxy="localhost,127.0.0.1,192.168.0.0/24"

这样的答案。但是实际使用的过程中，我发现这跟我就是在误导别人，因为如果像上面那样写，你在访问 192.168.0.1 的时候会发现还是走了代理。

经过尝试，下面几种写法都是无效的：

127.0.0.0
127.0.0.0/8
127/8
127.*.*.*
127.

特此记录一下，避免后人踩坑。。。

MYSQL的NOW和SYSDATE函数的区别

by Orange

在MySQL Performance Blog博客上看到一篇文章介绍now()和sysdate()函数。

想起很多朋友专门问在MySQL里面提供now()和sysdate()函数，都是表示取得当前时间，他们之间有什么区别。我们下面来详细看一下

首先大家可以看一下下面的一个诡异现象：

mysql> SELECT NOW(),SYSDATE();
+---------------------+---------------------+
| NOW() | SYSDATE() |
+-----------------------------+----------------------------+
| 1999-01-01 00:00:00 | 2012-12-05 09:50:03 |
+---------------------------+----------------------------+
1 row in set (0.00 sec)

很有意思吧？
sysdate()得到的时间是当前时间，而now()取出来的时间竟然是“1999-01-01 00:00:00”。
首先申明，我不是PS或者修改得来的，你看完本文，我会教你在你的MySQL上也得出这样的结果。

另外我们看一下，now()和sysdate()的另外一个区别：

mysql> SELECT NOW(), SLEEP(2), NOW();
+---------------------+----------+---------------------+
| NOW() | SLEEP(2) | NOW( |
+-----------------------------+--------------+-----------------------------+
| 2006-04-12 13:47:36 | 0 | 2006-04-12 13:47:36 |
+---------------------------+--------------+----------------------------+

mysql> SELECT SYSDATE(), SLEEP(2), SYSDATE();
+---------------------+----------+---------------------+
| SYSDATE() | SLEEP(2) | SYSDATE() |
+-----------------------------+--------------+----------------------------+
| 2006-04-12 13:47:44 | 0 | 2006-04-12 13:47:46 |
+---------------------------+--------------+----------------------------+

在使用now()的情况下，虽然我们sleep了2秒，但是大家可以看到两次now()函数输出的结果都是’2006-04-12 13:47:36′
而使用sysdate()的情况下，是两个时间’2006-04-12 13:47:44′,’2006-04-12 13:47:46’，正好相差两秒。

这个最终的原因，大家可以直接查看MySQL的reference对now()函数的解释：http://dev.mysql.com/doc/refman/5.6/en/date-and-time-functions.html#function_now
我简单给大家翻译一下。
now()函数，返回的是当前的时间。但是当前的时间是怎么取的列？

首先，对于now()函数来说，它取的时间是语句开始执行的那个时间，并且在语句执行过程中，这个值都不会变。甚至于，你在执行一个存储过程或者触发器时，这个值都是一直不变的。

这也就解释了，为什么sleep了2秒以后，在SELECT NOW(), SLEEP(2), NOW();语句中，取出的时间值是同一个：’2006-04-12 13:47:36’。

 

然后：now()函数取的当前时间从哪里来？它取自mysql的一个变量”TIMESTAMP”。

很奇怪吧？

其实这个是由于MySQL的replication导致的。你可以想象一下，一个insert into  gguard values (3,now());语句在两台MySQL上插入的值是不是一样？now()如果像sysdate()一样取的是机器的系统时间，那么在MySQL的主库和备库执行同一个这样的SQL语句，主库和备库的这一条数据肯定就不一致了。

主备库不一致的问题必须要解决，两种解决方式：

1、修复这种问题。

2、不使用statement的语句级别复制，而是类似于oracle的，将数据变更记录下来，原样在备库执行一遍。

第二种方式就是大家熟知的，binlog_format=ROW的方式。第一种就是now()不使用机器系统时间，而是取mysql的变量”TIMESTAMP”值。

另外的类似的变量还包括insert_id（用于复制时，AUTO_INCREMENT的取值）等

 

利用mysqlbinlog你可以看到每个binlog event都有一个时间值。

# at 441
#121205 10:06:52 server id 5 end_log_pos 526 Query thread_id=5 exec_time=0 error_code=0
SET TIMESTAMP=1354673212.982122/*!*/;
BEGIN
/*!*/;
# at 526
#121205 10:06:52 server id 5 end_log_pos 642 Query thread_id=5 exec_time=0 error_code=0
use `test`/*!*/;
SET TIMESTAMP=1354673212.982122/*!*/;
insert into gguard values (3,now())
/*!*/;
# at 642
#121205 10:06:52 server id 5 end_log_pos 669 Xid = 26
COMMIT/*!*/;

备库复制执行时，SQL thread在做每个insert或者其他操作前首先要执行SET TIMESTAMP这样的动作，保证now()函数在statement模式下在备库和主库一样。
这里还有另外一种含义：sysdate()函数在statement模式下，主库和备库会不一致，也就是说sysdate在statement复制模式下是不安全的。

 

那么怎么实现上面的SELECT NOW(),SYSDATE();查询出来的时间不一样列，你只需要在之前执行：

SET TIMESTAMP=UNIX_TIMESTAMP('1999-01-01');
SELECT NOW(),SYSDATE();

 
体验now()和sysdate()的神秘吧 🙂

注意：

CURRENT_TIMESTAMP() LOCALTIME() LOCALTIMESTAMP()都是now()函数的同义词，不讨论。
sysdate()没有同义词。
如果你觉得now()函数就够了，你不需要每次都取当前的机器系统时间，那么你可以在MySQL启动时指定–sysdate-is-now，这样的话MySQL会把sysdate()当成now()的一个同义词。

参考：
http://www.mysqlperformanceblog.com/2012/11/28/replication-of-the-now-function-also-time-travel/

[Redis] redis-cli 命令总结

by Orange

Redis提供了丰富的命令（command）对数据库和各种数据类型进行操作，这些command可以在Linux终端使用。在编程时，比如使用Redis 的Java语言包，这些命令都有对应的方法。下面将Redis提供的命令做一总结。

官网命令列表：http://redis.io/commands （英文）

1、连接操作相关的命令

  • quit：关闭连接（connection）
  • auth：简单密码认证

2、对value操作的命令

  • exists(key)：确认一个key是否存在
  • del(key)：删除一个key
  • type(key)：返回值的类型
  • keys(pattern)：返回满足给定pattern的所有key
  • randomkey：随机返回key空间的一个key
  • rename(oldname, newname)：将key由oldname重命名为newname，若newname存在则删除newname表示的key
  • dbsize：返回当前数据库中key的数目
  • expire：设定一个key的活动时间（s）
  • ttl：获得一个key的活动时间
  • select(index)：按索引查询
  • move(key, dbindex)：将当前数据库中的key转移到有dbindex索引的数据库
  • flushdb：删除当前选择数据库中的所有key
  • flushall：删除所有数据库中的所有key

3、对String操作的命令

  • set(key, value)：给数据库中名称为key的string赋予值value
  • get(key)：返回数据库中名称为key的string的value
  • getset(key, value)：给名称为key的string赋予上一次的value
  • mget(key1, key2,…, key N)：返回库中多个string（它们的名称为key1，key2…）的value
  • setnx(key, value)：如果不存在名称为key的string，则向库中添加string，名称为key，值为value
  • setex(key, time, value)：向库中添加string（名称为key，值为value）同时，设定过期时间time
  • mset(key1, value1, key2, value2,…key N, value N)：同时给多个string赋值，名称为key i的string赋值value i
  • msetnx(key1, value1, key2, value2,…key N, value N)：如果所有名称为key i的string都不存在，则向库中添加string，名称key i赋值为value i
  • incr(key)：名称为key的string增1操作
  • incrby(key, integer)：名称为key的string增加integer
  • decr(key)：名称为key的string减1操作
  • decrby(key, integer)：名称为key的string减少integer
  • append(key, value)：名称为key的string的值附加value
  • substr(key, start, end)：返回名称为key的string的value的子串

4、对List操作的命令

  • rpush(key, value)：在名称为key的list尾添加一个值为value的元素
  • lpush(key, value)：在名称为key的list头添加一个值为value的 元素
  • llen(key)：返回名称为key的list的长度
  • lrange(key, start, end)：返回名称为key的list中start至end之间的元素（下标从0开始，下同）
  • ltrim(key, start, end)：截取名称为key的list，保留start至end之间的元素
  • lindex(key, index)：返回名称为key的list中index位置的元素
  • lset(key, index, value)：给名称为key的list中index位置的元素赋值为value
  • lrem(key, count, value)：删除count个名称为key的list中值为value的元素。count为0，删除所有值为value的元素，count>0从头至尾删除count个值为value的元素，count<0从尾到头删除|count|个值为value的元素。 lpop(key)：返回并删除名称为key的list中的首元素 rpop(key)：返回并删除名称为key的list中的尾元素 blpop(key1, key2,… key N, timeout)：lpop命令的block版本。即当timeout为0时，若遇到名称为key i的list不存在或该list为空，则命令结束。如果timeout>0，则遇到上述情况时，等待timeout秒，如果问题没有解决，则对keyi+1开始的list执行pop操作。
  • brpop(key1, key2,… key N, timeout)：rpop的block版本。参考上一命令。
  • rpoplpush(srckey, dstkey)：返回并删除名称为srckey的list的尾元素，并将该元素添加到名称为dstkey的list的头部

5、对Set操作的命令

  • sadd(key, member)：向名称为key的set中添加元素member
  • srem(key, member) ：删除名称为key的set中的元素member
  • spop(key) ：随机返回并删除名称为key的set中一个元素
  • smove(srckey, dstkey, member) ：将member元素从名称为srckey的集合移到名称为dstkey的集合
  • scard(key) ：返回名称为key的set的基数
  • sismember(key, member) ：测试member是否是名称为key的set的元素
  • sinter(key1, key2,…key N) ：求交集
  • sinterstore(dstkey, key1, key2,…key N) ：求交集并将交集保存到dstkey的集合
  • sunion(key1, key2,…key N) ：求并集
  • sunionstore(dstkey, key1, key2,…key N) ：求并集并将并集保存到dstkey的集合
  • sdiff(key1, key2,…key N) ：求差集
  • sdiffstore(dstkey, key1, key2,…key N) ：求差集并将差集保存到dstkey的集合
  • smembers(key) ：返回名称为key的set的所有元素
  • srandmember(key) ：随机返回名称为key的set的一个元素

6、对zset（sorted set）操作的命令

  • zadd(key, score, member)：向名称为key的zset中添加元素member，score用于排序。如果该元素已经存在，则根据score更新该元素的顺序。
  • zrem(key, member) ：删除名称为key的zset中的元素member
  • zincrby(key, increment, member) ：如果在名称为key的zset中已经存在元素member，则该元素的score增加increment；否则向集合中添加该元素，其score的值为increment
  • zrank(key, member) ：返回名称为key的zset（元素已按score从小到大排序）中member元素的rank（即index，从0开始），若没有member元素，返回“nil”
  • zrevrank(key, member) ：返回名称为key的zset（元素已按score从大到小排序）中member元素的rank（即index，从0开始），若没有member元素，返回“nil”
  • zrange(key, start, end)：返回名称为key的zset（元素已按score从小到大排序）中的index从start到end的所有元素
  • zrevrange(key, start, end)：返回名称为key的zset（元素已按score从大到小排序）中的index从start到end的所有元素
  • zrangebyscore(key, min, max)：返回名称为key的zset中score >= min且score <= max的所有元素 zcard(key)：返回名称为key的zset的基数 zscore(key, element)：返回名称为key的zset中元素element的score zremrangebyrank(key, min, max)：删除名称为key的zset中rank >= min且rank <= max的所有元素 zremrangebyscore(key, min, max) ：删除名称为key的zset中score >= min且score <= max的所有元素
  • zunionstore / zinterstore(dstkeyN, key1,…,keyN, WEIGHTS w1,…wN, AGGREGATE SUM|MIN|MAX)：对N个zset求并集和交集，并将最后的集合保存在dstkeyN中。对于集合中每一个元素的score，在进行AGGREGATE运算前，都要乘以对于的WEIGHT参数。如果没有提供WEIGHT，默认为1。默认的AGGREGATE是SUM，即结果集合中元素的score是所有集合对应元素进行SUM运算的值，而MIN和MAX是指，结果集合中元素的score是所有集合对应元素中最小值和最大值。

7、对Hash操作的命令

  • hset(key, field, value)：向名称为key的hash中添加元素field<—>value
  • hget(key, field)：返回名称为key的hash中field对应的value
  • hmget(key, field1, …,field N)：返回名称为key的hash中field i对应的value
  • hmset(key, field1, value1,…,field N, value N)：向名称为key的hash中添加元素field i<—>value i
  • hincrby(key, field, integer)：将名称为key的hash中field的value增加integer
  • hexists(key, field)：名称为key的hash中是否存在键为field的域
  • hdel(key, field)：删除名称为key的hash中键为field的域
  • hlen(key)：返回名称为key的hash中元素个数
  • hkeys(key)：返回名称为key的hash中所有键
  • hvals(key)：返回名称为key的hash中所有键对应的value
  • hgetall(key)：返回名称为key的hash中所有的键（field）及其对应的value

8、持久化

  • save：将数据同步保存到磁盘
  • bgsave：将数据异步保存到磁盘
  • lastsave：返回上次成功将数据保存到磁盘的Unix时戳
  • shundown：将数据同步保存到磁盘，然后关闭服务

9、远程服务控制

  • info：提供服务器的信息和统计
  • monitor：实时转储收到的请求
  • slaveof：改变复制策略设置
  • config：在运行时配置Redis服务器

Redis高级应用
1、安全性
设置客户端连接后进行任何操作指定前需要密码，一个外部用户可以再一秒钟进行150W次访问，具体操作密码修改设置redis.conf里面的requirepass属性给予密码，当然我这里给的是primos
之后如果想操作可以采用登陆的时候就授权使用:
sudo /opt/java/redis/bin/redis-cli -a primos
或者是进入以后auth primos然后就可以随意操作了

2、主从复制
做这个操作的时候我准备了两个虚拟机，ip分别是192.168.15.128和192.168.15.133
通过主从复制可以允许多个slave server拥有和master server相同的数据库副本
具体配置是在slave上面配置slave
slaveof 192.168.15.128 6379
masterauth primos
如果没有主从同步那么就检查一下是不是防火墙的问题，我用的是ufw，设置一下sudo ufw allow 6379就可以了
这个时候可以通过info查看具体的情况

3、事务处理
redis对事务的支持还比较简单，redis只能保证一个client发起的事务中的命令可以连续执行，而中间不会插入其他client的命令。当一个client在一个连接中发出multi命令时，这个连接会进入一个事务的上下文，连接后续命令不会立即执行，而是先放到一个队列中，当执行exec命令时，redis会顺序的执行队列中的所有命令。
比如我下面的一个例子
set age 100
multi
set age 10
set age 20
exec
get age –这个内容就应该是20
multi
set age 20
set age 10
exec
get age –这个时候的内容就成了10，充分体现了一下按照队列顺序执行的方式
discard 取消所有事务，也就是事务回滚
不过在redis事务执行有个别错误的时候，事务不会回滚，会把不错误的内容执行，错误的内容直接放弃，目前最新的是2.6.7也有这个问题的
乐观锁
watch key如果没watch的key有改动那么outdate的事务是不能执行的

4、持久化机制
redis是一个支持持久化的内存数据库
snapshotting快照方式，默认的存储方式，默认写入dump.rdb的二进制文件中，可以配置redis在n秒内如果超过m个key被修改过就自动做快照
append-only file aof方式，使用aof时候redis会将每一次的函 数都追加到文件中，当redis重启时会重新执行文件中的保存的写命
令在内存中。
5、发布订阅消息 sbusribe publish操作，其实就类似linux下面的消息发布
6、虚拟内存的使用
可以配置vm功能，保存路径，最大内存上线，页面多少，页面大小，最大工作线程
临时修改ip地址ifconfig eth0 192.168.15.129

redis-cli参数
Usage: redis-cli [OPTIONS] [cmd [arg [arg …]]]
-h Server hostname (default: 127.0.0.1)
-p Server port (default: 6379)
-s Server socket (overrides hostname and port)
-a Password to use when connecting to the server
-r Execute specified command N times
-i When -r is used, waits seconds per command.
It is possible to specify sub-second times like -i 0.1
-n Database number
-x Read last argument from STDIN
-d Multi-bulk delimiter in for raw formatting (default: \n)
-c Enable cluster mode (follow -ASK and -MOVED redirections)
–raw Use raw formatting for replies (default when STDOUT is not a tty)
–latency Enter a special mode continuously sampling latency
–slave Simulate a slave showing commands received from the master
–pipe Transfer raw Redis protocol from stdin to server
–bigkeys Sample Redis keys looking for big keys
–eval Send an EVAL command using the Lua script at
–help Output this help and exit
–version Output version and exit

Examples:
cat /etc/passwd | redis-cli -x set mypasswd
redis-cli get mypasswd
redis-cli -r 100 lpush mylist x
redis-cli -r 100 -i 1 info | grep used_memory_human:
redis-cli –eval myscript.lua key1 key2 , arg1 arg2 arg3
(Note: when using –eval the comma separates KEYS[] from ARGV[] items)

常用命令：
1） 查看keys个数
keys * // 查看所有keys
keys prefix_* // 查看前缀为”prefix_”的所有keys

2） 清空数据库
flushdb // 清除当前数据库的所有keys
flushall // 清除所有数据库的所有keys

基于HTTP返回头信息的服务器时间同步

by Orange

因为偶尔遇到由于各种原因，我们在使用ntpdate的时候无法成功的跟服务器同步时间的现象，而一般情况下我们对时间的精度要求都不是太高，所以想到可以使用根据HTTP头里面的信息来校时的做法。
之前看到一个使用php编写的脚本，但是考虑到很多机器是没有php环境的，因此选用shell来进行代码的编写，尽量保证通用。

PS：这篇文章正好测试一下Gist插件，看看效果如何。