使用命令启动，报错
/sbin/rabbitmq-server -v |
关键错误信息 Protocol 'inet_tcp': register/listen error: ehostunreach，根据提示，可能是某个地址不可达，rabbitmq 启动时需要连接 epmd ，默认端口为 4369，在本地测试连接此端口，发现不通 [1]
curl -v 127.0.0.1:4369 |
根据输出的错误可知，是因为 127.0.0.1 无法连接，检查 iptables 防火墙策略，发现未允许回环网卡访问，在 iptables 中添加以下规则允许回环网卡访问
*filter |
允许回环网卡访问后，重新测试连接 epmd ，可以正常连接，重新启动 rabbitmq-server 正常。
curl -v 127.0.0.1:4369 |
Macvlan 本身是 linxu kernel 模块
Macvlan 接口是物理以太网接口的虚拟子接口，Macvlan 允许用户在一个物理网络接口上面配置多个虚拟的网络接口，每个 Macvlan 接口都有自己的区别与父接口的 MAC 地址，并且可以像普通的物理网络接口一样分配 IP 地址。使用 Macvlan 技术实现的效果是一块物理网卡可以绑定多个 IP 地址，并且每个 IP 地址有自己独立的 MAC 地址。
Macvlan 虚拟出来的虚拟网卡，在逻辑上和物理网卡是对等的。使用 Macvlan 的虚拟网卡要和父接口在同一个网段。
Macvlan 的最大优点是性能极好，相比其他方式，macvlan 不需要创建 Linux bridge，而是直接通过interface 连接到物理网络。
为保证父接口能接收多个不同 MAC 地址的网络包，需要开启网卡的 混杂模式
本示例演示 docker 环境中使用 macvlan。首先创建使用 macvlan 驱动的 network，Docker 中 macvlan 只支持 bridge 模式 [1]
docker network create -d macvlan --subnet=192.168.142.0/24 \ |
在 docker 环境中，创建网络时，会自动将宿主机网卡设置为混杂模式，此时查看网卡信息，未显示混杂模式，但是查看
dmesg日志，会看到网卡进入了混杂模式
[93203.228311] device ens33 entered promiscuous mode
运行容器并连接到新建的 macvlan 网络 macvlan1
docker run -itd --name test01 \ |
使用命令 docker exec -it test01 bash 进入容器查看容器的 IP 地址信息，可以看到容器中的网卡类型为 macvlan，模式为 bridge，网关为 docker 网络 macvlan1 中配置的网关。
ip -d add |
测试容器可以和宿主机网络一样访问外网。
此时检查宿主机网卡信息，系统上只有 lo，ens33，docker0，未出现其他网卡。
ip -d link |
在另一个 docker 节点上同样配置 docker 网络和容器
docker network create -d macvlan --subnet=192.168.142.0/24 \ |
进入容器 test01 ，访问到另一个节点上的容器的连通性
ping 192.168.142.12 |
进入容器 test01 ，测试和宿主机 ip 的连通性，结果发现不通，原因为：在 macvlan 虚拟网络中，父接口（物理网卡）相当于一个交换机，对于其子 macvlan 网卡的数据包，只进行转发而不处理，于是造成了使用本机 macvlan 网卡的虚拟 IP 无法和本机物理网卡的 IP 通信。
ping 192.168.142.10 |
Linux 的 namespace 的作用是 隔离内核资源，目前主要实现了以下 namespace
mount namespace - 文件系统挂载点UTS namespace - 主机名IPC namespace - POSIX 进程间通信消息队列PID namespace - 进程 pid 数字空间network namespace - networkuser namespace - user ID 数字空间其中，除了 network namespace，其他 namespace 的操作需要使用 C 语言调用系统 API 实现。network namespace 的增删改查功能已经集成到了 Linux 的 ip 工具集的 netns 子命令中
Linux 里面的 namespace 给处在其中的进程造成 2 个错觉：
默认情况下，Linux 里面的所有进程处在和宿主机相同的 namespace ，即初始 namespace 里，默认享有全局系统资源。
network namespace 的增删改查功能已经集成到了 Linux 的 ip 工具集的 netns 子命令中，因此在 Linux 系统中，对 network namespace 的操作主要使用 ip netns 命令
ip netns help |
使用以下命令创建名为 netns1 的 network namespace
ip netns add netns1 |
以下命令查看系统中的 network namespace
ip netns list |
新的 network namespace 创建后，系统会在 /var/run/netns/ 下面生成一个同名的挂载点
ls -l /var/run/netns/ |
此挂载点的主要作用一方面是方便对 namespace 的管理，一方面是使 namespace 即使没有进程运行也能继续存在。
新的 network namespace 创建后，可以使用 ip netns exec 命令进入 namespace，做网络配置或者查询的工作。
ip netns exec命令只能根据 network namespace 的名称进入 namespace
以下命令查询 netns1 的 network namespace 的 IP 地址信息
ip netns exec netns1 ip add |
默认的 network namespace 除了附带一个 lo 网卡外，没有任何其他网络设备，并且此 lo 接口还处于 DOWN 的状态，因此此回环网卡也是不可访问的。
ip netns exec netns1 ping 127.0.0.1 |
在此示例中，如果想启用本地回环地址，首先需要进入 namespace，将本地回环网卡的状态修改为 UP
ip netns exec netns1 ip link set dev lo up |
此时，namespace 中的 lo 网卡可以正常使用，但是因为 namespace 中没有其他网络设备，此 network namespace 无法和其他网络通信，要和其他网络通信，需要用到其他的网络技术，例如 veth pair
要删除 network namespace，可以使用以下命令
ip netns delete netns1 |
上面这条命令并没有实际删除
netns1这个network namespace，它只是移除了这个 namespace 对应的挂载点(/var/run/netns/netns1)，只要里面的进程还运行着，network namespace就会一直存在
veth 是虚拟以太网（Virtual Ethernet）的缩写。veth 设备总是成对出现的，因此我们称之为 veth pair，veth pair 的一端发送的数据会在另外一端接收。根据这一特性，veth pair 常被用于跨 network namespace 的通信，即分别将 veth pair 的 2 端放在不同的 network namespace。
从 Linux 文件系统的角度看，tun/tap 设备是用户可以使用文件句柄操作的字符设备
从 Linux 网络虚拟化的角度看，tun/tap 设备是虚拟网卡，一端连接内核网络协议栈，一端连接用户态的程序。
tun/tap 设备主要的作用是可以将 TCP/IP 协议栈处理好的数据包发送给任何一个使用 tun/tap 设备驱动的程序，由用户态程序重新处理数据包后重新发送到 TCP/IP 协议栈。
tun/tap 设备的工作原理完全相同，主要区别在于：
上图展示了物理设备上的数据是如何通过 Linux 内核网络协议栈发送到用户态程序的。
物理网卡的数据送达网络协议栈，进程通过 Socket 创建特殊套接字，从网络协议栈接收数据。
从网络协议栈的角度看，tun/tap 设备这类虚拟网卡与物理网卡并无区别。对 tun/tap 设备而言，他与物理网卡的不同表现在它的数据源不是物理链路，而是来自用户态。
普通的物理网卡通过网线收发数据包，而 tun/tap 设备通过一个设备文件 （/dev/tunX，/dev/tapX）收发数据包，所有对这个文件的写操作会通过 tun/tap 设备转换成一个网络数据包传送给内核的网络协议栈。当内核网络协议栈发送一个包给 tun/tap 设备时，用户态的进程通过读取设备文件，就可以拿到报的内容。用户态的程序也可以通过写入这个设备文件向 tun/tap 设备发送数据。
如上图所示，整个数据包的流程包括
综上所述，发到 192.168.1.0/24 的数据包，首先通过监听在 tun0 设备上的 App2 （VPN 客户端）进行封包，再利用物理网卡 eth0 发送到远端网络的物理网卡上，从而实现 VPN。
VPN 网络报文真正从物理网卡出去需要经过 2 次内核网络协议栈，因此会有一定的性能损耗。
Linux 的 namespace 的作用是 ”隔离内核资源“，目前主要实现了以下 namespace
mount namespace - 文件系统挂载点UTS namespace - 主机名IPC namespace - POSIX 进程间通信消息队列PID namespace - 进程 pid 数字空间network namespace - networkuser namespace - user ID 数字空间cgroup - 资源使用控制其中，除了 network namespace，其他 namespace 的操作需要使用 C 语言调用系统 API 实现。network namespace 的增删改查功能已经集成到了 Linux 的 ip 工具集的 netns 子命令中
Linux 里面的 namespace 给处在其中的进程造成 2 个错觉：
默认情况下，Linux 里面的所有进程处在和宿主机相同的 namespace ，即初始 namespace 里，默认享有全局系统资源。
想要查看某个进程都在哪些 namespace 中，可以找到进程 ID （PID），通过查看以下内容或者 namespace 信息
ps -elf | grep nginx |
通过以上命令，可以看到 nginx 进程所属的 namespace，要查看系统初始 namespace ，可以查看 PID 为 1 的进程的 namespace 信息
ll /proc/1/ns/ |
链接文件的内容的格式为 ns 类型: [inode number]。这里的
inode number则用来标识一个 namespace，我们也可以把它理解为 namespace 的 ID。如果两个进程的某个 namespace 文件指向同一个链接文件，说明其相关资源在同一个 namespace 中。 [1]
sysctl 命令被用于在内核运行时动态地修改内核的运行参数，可用的内核参数在目录 /proc/sys 中。
sysctl 命令对内核参数的修改仅在当前生效，重启系统后参数丢失。如果希望参数永久生效可以修改配置文件 /etc/sysctl.conf。
| 内核参数 | 取值范围 | 含义 | 使用说明 |
|---|---|---|---|
kernel.hung_task_timeout_secs = 120 |
int | 设置系统检测到进程阻塞(如 `D` 状态)后，等待进程结束的时常。 如果进程未在规定时间内结束，系统认为该进程无响应，则自动杀死以避免系统奔溃 |
| 内核参数 | 取值范围 | 含义 | 使用说明 |
|---|---|---|---|
vm.min_free_kbytes = 2097152 |
单位 KB |
设置系统最小剩余内存，以避免缓存不释放导致的死机 | |
vm.oom-kill = 0 |
0,1 默认值为 1，开启 |
是否启用 OOM-killer。 特定情况下，可能不希望核心执行 OOM killer 的工作,关闭 OOM killer。 例如，排错时 echo 0 > /proc/sys/vm/oom-kill 临时关闭 [1] |
|
vm.overcommit_memory = 0 |
0,1,2 | 内存分配策略/proc/sys/vm/overcommit_memory |
vm.overcommit_memory 详细说明 |
vm.overcommit_ratio = 50 |
int default = 50 |
vm.overcommit_memory = 2 时才生效，配置允许 overcommit 的百分比 |
vm.overcommit_memory 详细说明 |
vm.panic_on_oom = 0 |
0,1 默认为 0 ，开启 |
表示当内存耗尽时，内核会触发 OOM killer 杀掉最耗内存的进程 | |
vm.oom_kill_allocating_task = 0 |
0,1 默认为 0 ，不启用 |
OOM-Killer 时，是否选择当前正在申请内存的进程进行 kill |
本文档中的日志分析主要依赖于 journald 服务记录的日志，因此首先需要对 `journald` 服务记录的日志进行持久化配置
k8s 节点经常出现无响应(死机)，重启才能恢复正常。重启恢复后，检查系统 messages 日志。
Feb 10 12:21:40 k8s-work1 kernel: INFO: task dockerd:1443 blocked for more than 368 seconds. |
从日志中可看出，dockerd 进程处于 `D` 状态，说明 dockerd 在等待 IO 操作，根据进程调用的栈信息，显示存在对 overlay 文件系统的同步操作，初步猜测，可能是因为 overlay 文件系统中的某些操作未能及时完成，导致了 dockerd 进程的阻塞。
继续检查日志，看到系统连接 NFS 服务超时，怀疑可能是因为 NFS 异常导致。
Feb 10 12:21:40 k8s-work1 kernel: nfs: server 172.31.88.9 not responding, timed out |
Linux 网卡的混杂模式（Promiscuous mode），简称 Promisc mode，俗称 监听模式。在非混杂模式下，网卡只会接受目的 MAC 地址是它自己的单播帧，以及多播帧；在混杂模式下，网卡会接受经过它的所有帧。
查看网卡是否处于 Promiscuous mode，可以使用 ifconfig 或者 netstat -i 命令
ifconfig ens33 |
当输出包含 PROMISC 时，表明该网络接口处于 Promiscuous mode，否则表明未处于 Promiscuous mode。要开启网卡的 Promiscuous mode ，可以使用以下命令
ifconfig ens33 promisc |
以下命令使网卡退出 Promiscuous mode
ifconfig ens33 -promisc |
将网络设备加入 Linux bridge 后，网络设备会自动进入混杂模式，此种情况使用 ifconfig 或者 netstat -i 命令查看网卡，未显示 PROMISC，但是查看内核日志，显示网卡已进入混杂模式，并且无法退出，直到将 veth 从Linux bridge 中移除。网络设备移除网桥后，会自动退出混杂模式。
ip link add veth0 type veth peer name veth1 |
Django 自带的 Admin Site 管理页面可以方便用户快速构建一个简单的后台管理系统，少量代码即可快速实现对数据库中的数据进行展示、修改、保存的可视化页面和功能。当需要对后台展示的数据进行配置时，只需要在 app 的代码文件 admin.py 中进行相应配置即可。
要为 model 启用 admin 管理接口，参考配置
wget https://repo.mongodb.org/yum/redhat/7/mongodb-org/4.0/x86_64/RPMS/mongodb-org-shell-4.0.28-1.el7.x86_64.rpm |
Django 模板之间存在各种复杂的继承关系，最基础的模板为 base.html，文件位于 python3.11/site-packages/django/contrib/admin/templates/admin/base.html。下面以 Admin 页面中的各个模块来解析实现对应模块的模板及代码。
title 指网页标题，以 Admin 站点的首页为例，首页的模板文件 index.html 中未定义 title 信息，而是继承自 base_site.html
{% extends "admin/base.html" %} |
base_site.html 模板继承了模板 base.html，并使用 {% block title %} 标签复写了继承自 base.html 模板的 title 信息。默认显示 Django site admin，如果应用的 admin.py 中定义了 admin.site.site_title，则显示其内容
{% load i18n static %}<!DOCTYPE html> |
基础模板 base.html 中 title 信息默认为空。
Admin 管理页面最顶部左上角会展示默认的 Django 管理 或者站点标题，如果应用的 admin.py 中配置了 admin.site.site_header，则显示站点标题，这是一个链接，点击后会跳转首页。
这部分的实现是通过继承 base_site.html 实现，其中的 {% block branding %} 定义了这部分内容。
{% extends "admin/base.html" %} |
Django admin 站点默认会显示如下的欢饮信息及修改密码、注销等链接
此处的配置位于 base.html 中的 {% block usertools %} 块内，{% block usertools %} 块位于 {% block header %} 块内。
{% block header %} |
如果要自定义自己的页面，并实现和 Django admin 一致的风格，比如一样的 branding 和用户欢迎信息，可以使用如下代码实现
{% extends "admin/base_site.html" %} |
SELECT * FROM [TABLE] |
参数说明：
into outfile ‘导出的目录和文件名’ fields terminated by ‘字段间分隔符’ optionally enclosed by ‘字段包围符’
optionally enclosed by对数值型字段无效
lines terminated by ‘行间分隔符’ 产生报错可参考 Mysql 常见错误
insert into tb(c1,c2) values(1,2),(3,4),(5,6); |
错误场景 ： windows 系统中 git push 报错
错误原因 ： 大概率为用户密码错误
排查步骤 ：
.git/config 文件，对 url 按照如下格式配置：url = http://[email protected]/test.git |
USERNAME 为用户名，重新执行 git push，此时会要求输入用户密码，输入正确的用户密码后，可正常执行执行 git pull 命令时报错：
git pull |
此错误原因为本地的分支（activity）未和远程分支建立关联，根据提示，执行以下命令建立关联关系
git branch --set-upstream-to=origin/activity origin/xhy-activity |
执行报错： fatal: Ambiguous object name: 'origin/activity'.，此报错原因为本地已存在分支 origin/activity，远程也存在此分支，导致 git 无法分辨。可以执行以下命令重命名本地分支
git branch -m origin/activity activity |
重新建立关联关系
git branch --set-upstream-to=origin/activity activity |
关联正常后，执行 git pull 正常。
调用 API 接口需要使用 API key 及账号密码。API 接口申请 key 时需要添加 IP 白名单，只允许从添加的白名单 IP 请求 API。
API 默认返回的数据格式为 TEXT，建议指定数据返回格式为 JSON，通过 eval(response.content) 将返回的字节类型数据转换为字典类型。
params = {'ApiKey': 'key', 'Password': 'pswd', 'ResponseFormat': 'JSON'} |
params = {'ApiKey': 'key', 'Password': 'pswd', 'ResponseFormat': 'JSON'} |
Python SDK 为 python-namesilo，安装方法
pip install python-namesilo |
使用 SDK 之前需要先登陆账号创建 API Token，详细使用方法可以查看帮助信息，获取所有域名使用方法 list_domains
from namesilo.core import NameSilo |
获取指定域名的详细信息使用 get_domain_info，此方法返回一个 DomainInfo 对象，里面包括域名创建时间，过期时间，nameserver等信息
client.get_domain_info('test.app') |
脚本内容如下，本示例中 Windows 版 rsync 客户端安装位置： d:\cwrsync_6.2.4_x64_free\，密码文件路径：d:\cwrsync_6.2.4_x64_free\rsync.client.pswd
|
宿主机操作系统内核配置允许数据转发，开启系统 IPv4 转发功能
用了在启动容器时挂载以持久化 OpenVPN 配置
mkdir /opt/openvpn1/ |
执行以下命令初始化 OpenVPN 服务端配置
docker run --rm \ |
参数说明：
udp://${PUB_IP}:1194 - 指定 VPN 服务器配置，使用 1194/udp 端口。${PUB_IP} 为服务器公网 IP。docker run --rm -it \ |
根据提示，输入 CA 根证书密码及名称
执行以下命令，根据提示输入客户端证书密码及 CA 密码，生成客户端证书。如果客户端证书无需密码，最后加选项 nopass
docker run --rm -it \ |
docker run --rm -it \ |
docker run -it --name OpenVPN1 \ |
防火墙放通 1194/udp 端口
-A INPUT -p udp --dport 1194 -j ACCEPT -m comment --comment "openvpn" |
OpenVPN 启动后，docker 会在宿主机操作系统的 iptables 中添加对应的 MASQUERADE 规则，负责转发和 NAT 数据，具体规则可通过以下方法查看
查看 NAT 表添加的规则
iptables -t nat -L -v -n --line-numbers | more |
查看 FILTER 表添加的规则
$ iptables -L -v -n --line-numbers | more |
将 导出客户端证书 中生成的客户端证书发送到客户端，测试连接。
客户端连接失败，可以检查以下内容：
客户端日志及服务端日志，服务端日志可以通过以下方法查看
docker logs -f OpenVPN |
检查是否是因为 iptables 防火墙规则 问题导致无法连接，如果防火墙相关规则丢失，可以通过重启 docker 和 OpenVPN 容器的方式恢复。
检查容器中启动的端口和 docker 映射的端口是否一致。
常用选项
| 选项 | 说明 | 示例 |
|---|---|---|
-c |
打包文件 | |
-x |
解包 | |
-t |
检测打包文件中的内容 | tar -tf test.tar |
-f |
目标文件名称，要打包或解包的文件名 | tar -cf test.tar test tar -xf test.tar |
--exclude |
打包时排除文件 打包的目录使用相对路径，排除的文件只能接相对路径 打包的目录使用绝对路径，排除的文件接相对路径或绝对路径 |
tar -cf test.tar test --exclude=runtime/* |