iterm 个性化的改动记录
更改前景色和背景色 如图
效果:
更改 Key Mappings
Profiles -> Keys -> Key Mappings -> Natural Text Editing. 这样做的好处是 FN + 左右箭头. Option + 箭头
效果:
Profiles -> Keys -> Key Mappings -> Natural Text Editing. 这样做的好处是 FN + 左右箭头. Option + 箭头
今天有空去看了下最近的这个站点的流量, 发现少了一些. 再看一周的流量, 也比以前少了. 之前至少每天有30~70的PV. 可是最近少了一半.
打开更长的周期和来源分析一下, 从5月开始,发现从百度来的明显减少了, 不知道是为什么? 最近几天几乎为0.
大概5月13号左右换过一次 IP. 但是看上去并不相关.
去看了下最近百度的抓取状态, 发现最近半个月没有任何抓取数据. 不知道是不是因为最近没有更新文章导致的.
在 MAC 上工作, 竟然遇到要更改 PATH 环境变量的情况. 比如有的 Java 工程是基于 JDK8 的, 有的是基于 JDK11 的, 所以经常要改这个变量. 那么我们看到的 PATH 环境变量是从哪里来的, 那些配置文件会改这些 PATH 值呢?
首先, 我们先看下当前的 PATH 变量:
~ xiatian$ echo $PATH
/usr/local//Cellar/curl/7.80.0_1/bin/:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Wireshark.app/Contents/MacOS:/Users/xiatian/work/tools:/Applications/Visual\ Studio\ Code.app/Contents/Resources/app/bin/
这里面有好多路径, 那么我们好奇当系统启动的过程中, 最初的 PATH 是什么呢?
MAC 上最初的 PATH 是从 /etc/paths
文件读的:
~ xiatian$ cat /etc/paths
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
然后, 它会把 /etc/path.d
里面的路径逐个添加到后面, 比如我们可以看到我的 wireshark 路径在上面的 PATH 里:
~ xiatian$ ls -l /etc/paths.d/
total 8
-rw-r--r-- 1 root wheel 43 Oct 19 2017 Wireshark
~ xiatian$ cat /etc/paths.d/Wireshark
/Applications/Wireshark.app/Contents/MacOS
.bash_profile
& .bash_rc
. 他们的区别是: 当一个 shell 是 login shell 的时候, 它会先执行 .bash_profile
, 当是一个非 login 交互式 shell 的时候, 它执行 .bashrc
. 但是在 MAC 上, 默认都是 login shell, 所以应该都执行. 来源于这个问答. 我试过了自带的 Terminal 和 安装的 iterm, 发现我的 MAC 都不是这么玩的.我本地是执行的 ~/.profile. 查看 bash 的 man, 你会在 INVOCATION section 看到具体的配置执行顺序:
~ xiatian$ man bash
When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.
When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc.
所以, 只要仔细阅读 man bash
的内容, 你就知道 PATH 是怎么变化的啦.
一本简短的关于 Linux 虚拟化方面的书, 涉及到虚拟机和container的一些核心概念, 挺好的.
<
VMM 基本功能:
内存虚拟化: guest OS 不能直接操作物理内存, 不能操作硬件 page tables. 一般Virtual Memory -> CR3 + MMU (硬件) -> 查找 page tables -> 物理内存; 对应 VMM 有了 3 层抽象
net namespace 相关的命令
1. ip netns add myns
2. ip netns del myns
3. ip netns exec myns sh ## 执行 sh 在 myns namespace
4. ip link add veth0 type veth peer name veth1 ##创建 veth 对 (veth0 ~ veth1)
5. ip link set veth1 netns myns ## 把 veth 的一端加到 myns namespace
CPU group:
Block I/O cgroup
Layered File System:
使用 Wireshark 分析 https 数据的时候, 尤其是分析网络为什么 reset 的时候, 经常看到有些数据行标注为: "Encrypted Alert", 紧接着就会看到连接主动/被动关闭或者 reset. 比如下图:
看到这 2 个单词, 我们很自然想到是不是加密过程出了什么问题? 为什么它提示 Alert? 今天我们具体去研究一下, 这个 "Encrypted Alert" 到底是什么, 跟连接断掉有什么关系?
首先, 我们研究一下这个 tcp 包的数据, 从下图可以看到, 它其实是传输层的数据, 没有应用层数据. 传输层的具体数据是: 它的内容类型(Content Type)是 Alert, 定义的 ID 是 21, 具体的 Alert Messge 就是: "Encrypted Alert". 从这里我们只能看到这个加密的会话出现了一个加密相关的告警, 没有其它可以告诉我们的.
另外, 在第一个截图中, 我们看到在 60 结尾的主机发 FIN 之前, 先发了一个 "Encrypted Alert" 消息, 接着发了 FIN. 之后 236 结尾的主机, 发了一个 "Encrypted Alert", 还没有发 FIN, 60 结尾的主机立马回了一个 RST.
首先, TLS 协议根据内容类型(Content Type)有四种可能的记录(record)类型.
根据 TLS 1.2 RFC5246, 这 4 种记录类型的编码分别是: 20, 21, 22, 23
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
具体到 TLS 的 record, alert(21) 类型的数据, 只用到了 Content Type, TLS 协议大小版本号, 数据长度, 数据.
对应我们上面截图中的数据:
根据 TLS 1.2 RFC5246, Alert 的数据分为 AlertLevel 和 AlertDescription 2 部分. AlertLevel描述严重性: Warning 和 Fatal. AlertDescription 描述具体的 Alert 原因. 不过他们都是 enum 类型. 具体的数据结构是:
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110),
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
那么有了上面比较全面的 Alert 的数据可能值, 我们能不能看出, 我们上面例子中具体的 Alert leve 和 alert decription 呢? 我们把看到的26 字节的数据和上面的任意一个对比, 都不能找到匹配的, 为什么呢?
根据上面的协议描述, 我们知道 Alert 的数据部分(level 和 description) 属于 payload 的部分, 而 payload 部分根据 RFC5246 是被加密和压缩的, 所以我们不能像找 header 部分的对应关系一样, 找到对应的数据.
Like other messages, alert messages are encrypted and compressed, as specified by the current connection state
我们知道, 可以通过 log sslkey 的方式, 把加密数据的关键key 记录下来, 然后让 Wireshark 解密的时候使用. 参考:
MAC 上解密 https 协议
Windows 上解密 https 协议
如果你使用 curl, 那就更方便了:
export SSLKEYLOGFILE=~/Downloads/keylog.log
开始抓包
$ host www.tianxiaohui.com
www.tianxiaohui.com has address 103.144.218.5
$ sudo tcpdump host 103.144.218.5 -w ~/Download/tianxiaohui.pcap
curl -vvv https://www.tianxiaohui.com/
如此设置之后, 我们就看到了解密之后的 payload: 它的 level 是 warning, 对应 0x1, 它的 description 是 0x0, 对应 close_notify.
看到这里, 大家可能突然明白, 针对我们最后使用 curl 访问 https 的这个例子, 这里的 close_notify 原来就是 TLS 协议的结束消息, 告诉对方, 这个 TLS session 要结束了. 类似于 tcp 协议的 FIN 消息. 当然 Alert 类型的里面, 还有更多的不同的 description, 不过我们这里的正好是 close_notify.
这样印证了, 在 Wireshark 知道 key 之前, 它根本无法知道具体的 alert 是什么. 所以, 我们仅仅根据 "Encrypted Alert" 这个消息, 也无法推断具体的 alert 是什么类型, 到底发生了什么.
参考: