转:shell中滚动显示全部内容，高亮显示查询内容

 

 只高亮，不漏日志

想让日志全部显示，但只把关键词标亮？试试这个：

bash

tail -f app.log | grep --line-buffered --color=always -E "ERROR|WARN|$"

技巧解析：在匹配模式最后加上 |$，它会匹配“行尾”，这样每一行日志都会被输出，但关键词部分依然会高亮显示。

转:获得5000个ip

 问题:生成5000个ip

解决:python3方式

 1 import ipaddress

  2 start_ip = ipaddress.IPv4Address("192.167.0.0")

  3 ips = [str(start_ip + i) for i in range(5000)]

  4 print(f"范围: {ips[0]} -> {ips[-1]}")

转:使用跳板机 两个主机ssh和scp

环境介绍当前在100.120 上，有个118.131 可以和它联通，

118.131和122.2 可以联通，但无法直接在100.120上直接联通

如果要ssh 可以【下面这个只要求118.131上有100.120的key】 

/bin/ssh -t root@192.168.118.131 "ssh root@192.168.122.2"

scp文件，这里要求122.2上有100.121的key

scp  -o ProxyJump=root@192.168.118.131 use_cmd root@192.168.122.2:~

ssh -o ProxyJump=root@192.168.118.131 root@192.168.122.2 "ls -all ~"

转:crictl ps提示[unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead.

 在虚拟机上完成上面master安装后，重启系统，关闭了firewall 后，出现错误

• 错误

  • # crictl ps|grep kube-apiserver WARN[0000] runtime connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead. WARN[0000] image connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead. E0410 14:43:54.969196 2572486 remote_runtime.go:390] "ListContainers with filter from runtime service failed" err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory\"" filter="&ContainerFilter{Id:,State:&ContainerStateValue{State:CONTAINER_RUNNING,},PodSandboxId:,LabelSelector:map[string]string{},}" FATA[0000] listing containers: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory"

• 解决

  • # cat > /etc/crictl.yaml << EOF

    > runtime-endpoint: unix:///run/containerd/containerd.sock

    > image-endpoint: unix:///run/containerd/containerd.sock

    > timeout: 10

    > debug: false

    > EOF

    [root@119-132 ~]# crictl ps

    CONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID              POD

    [root@119-132 ~]# systemctl restart kubelet

    [root@119-132 ~]# crictl ps |grep apiserver

    0d0963b6ea4b5       cdcab12b2dd16       21 seconds ago      Running             kube-apiserver            4                   4b240b09343c1       kube-apiserver-119-132

    [root@119-132 ~]# kubectl get nodes

    NAME      STATUS     ROLES           AGE   VERSION

    119-132   Ready      control-plane   36d   v1.28.2

    119-134   NotReady   <none>          35d   v1.28.2

    [root@119-132 ~]#

    应该是可以了

• 分析

  • 简单来说：第一次正常，是因为 crictl 侥幸“蒙对了”；重启后不正常，是因为环境变了，它“猜错了”。

    以下是详细的技术原因拆解：

    1. 第一次为什么正常？（侥幸命中默认列表）

    你第一次执行 crictl ps 时，它还没有配置文件，因此会使用内置的默认端点列表按顺序尝试连接：

    /var/run/dockershim.sock

    /run/containerd/containerd.sock <-- 你的在这里

    /run/crio/crio.sock

    /var/run/cri-dockerd.sock

    关键点： 当时你的环境里，第一个路径（dockershim.sock）不存在，但 crictl 报错后并没有立即退出，而是迅速尝试了第二个路径（containerd.sock），发现能连上，于是正常工作了。这让你产生了“没问题”的错觉。

    2. 重启后为什么不行了？（默认行为变了）

    重启电脑后，情况发生了微妙但关键的变化：

    运行时环境重置：某些系统服务或套接字文件的初始化顺序可能改变。

    crictl 的默认逻辑更严格了：在较新版本或某些系统配置下，crictl 在尝试第一个路径并遇到“致命”错误（如权限拒绝或文件不存在） 时，可能不会优雅地继续尝试下一个，而是直接抛出错误并退出。

    超时或阻塞：第一次尝试连接一个不存在的 dockershim.sock 可能会遇到更长的超时或更严重的错误，导致整个命令失败，根本没机会试到第二个路径。

    结果就是： 它卡在了第一个错误的路径上，根本没去尝试第二个正确的路径，所以你看不到容器。

    3. 配置 /etc/crictl.yaml 的本质作用

    你创建的配置文件，本质上是跳过了那个“猜”的过程，直接告诉 crictl：

    “别费劲试第一个了，直接去 /run/containerd/containerd.sock 找。”

转:win11 25H2版本安装提示要安装网卡驱动的跳过方式

 问题:win11 25H2版本安装提示要安装网卡驱动的跳过方式

来源:

https://chat.deepseek.com/share/17u5xzvr9y5vkli09f

对于 25H2 及更新版本（包括家庭版），可以尝试以下命令：

在联网界面按 Shift + F10 打开命令提示符，输入：

cmd

start ms-cxh:localonly

输入后系统会直接弹出本地账户创建界面，无需重启。

注意：微软已在 25H2 内部预览版中开始封堵此命令，可能在后续更新中彻底失效，建议尽快使用

转:esxi 8.0 安装win11

参考: 

https://www.php.cn/faq/2063503.html

当出现“这台电脑无法运行 Windows 11”的提示时（或在选择安装类型的界面），按 Shift + F10 打开命令提示符窗口。[popexizhi: 这里可以尝试直接输入Shift + F10]

第三步：通过命令行添加注册表项

依次执行以下三条命令：

cmd

reg add HKLM\SYSTEM\Setup\LabConfig /v BypassTPMCheck /t REG_DWORD /d 1 /f
reg add HKLM\SYSTEM\Setup\LabConfig /v BypassSecureBootCheck /t REG_DWORD /d 1 /f
reg add HKLM\SYSTEM\Setup\LabConfig /v BypassRAMCheck /t REG_DWORD /d 1 /f

其中 BypassRAMCheck 是可选的，用于跳过 4GB 内存检查。

第四步：关闭窗口继续安装

关闭命令提示符，点击安装界面左上角的返回箭头，然后再次点击“下一步”，检测提示就会消失，可以正常安装了。

转:dnf

 dnf 仓库

dnf repolist #列出启用仓库

def repolist all #列出仓库包含禁用的

#启用/禁用指定仓库

def config-manager --set-enabled epel

def config-manager --set-disabled epel

#添加三方仓库

dnf install epel-release

#缓存

dnf clean all 

dnf clean packages #只删除包缓存

dnf clean metadata #只删除元数据

dnf makecache      #生成缓存手动刷新用

#dnf与yum不同点

dnf history #可查询dnf的操作历史

dnf history info 12  #12是history中的事务id

dnf history undo 15  #插销第15次操作

dnf history rollback 10 #回滚到第10次之后的状态

#包组

dnf group list

dnf group info "Development Tools" #查看包组详情

def group install "Development Tools" #安装开发工具套件

dnf group rmmove "Development Tools" #卸载开发工具套件包组

转:kubectl

 #查询

kubectl get pods #查询全部的Pods (默认的命名空间)

kubectl get pods -o wide #查询更多信息:ip,所在节点,重启次数

kubectl get pods --all-namespaces #查询全部的命名空间的pod

#查询 Deployment ,Service,Node,PVC

kubectl get deployments 

kubectl get svc

kubectl get nodes

kubectl get pvc

#深入排查

kubectl describe pod <pod名称>  #查看pod的详细事件

kubectl describe node <node名称> #查看node的资源压力

get和describe的核心区别是: get -o yaml 看"配置长什么样", describe 看"集群里发生了什么"

#声明配置

kubectl apply -f deployment.yaml #创建或更新资源，可反复执行,幂等

kubectl delete -f deployment.yaml #删除资源

kubectl delete pod <pod名称>  #删除指定的pod

kubectl delete deployment <部署名称> #删除deloyment 对应的pod也随着删除

kubectl delete -f deployment.yaml #基于文件删除和apply对应

解释:

为什么用 apply 而不是 create？

create 是命令式，资源已存在时报错；apply 会计算 diff 并更新，与 GitOps 理念一致。

[popexizhi: GitOps理念 :

核心思想：三句话概括

- 整个系统用代码描述：K8s YAML、Terraform 配置、Helm Chart 全部放在 Git。

- Git 是唯一真相源：任何人想改配置，不许登录服务器敲命令，只能提交 Pull Request 改 Git。

- 自动同步：集群里有个“机器人”（如 ArgoCD、Flux）盯着 Git，发现差异就自动应用。

ps:反常识点：kubectl 在生产环境其实是“不推荐”的——因为它绕过了 Git，导致仓库和实际环境不一致。

幂等（Idempotent）最简单的理解是：“一次操作和多次操作，产生的结果是一样的”

]

转:virsh 基本使用

 

virsh list

virsh list --all

virsh start <虚拟机名称>    #开机

virsh shutdown <虚拟机名称> #关机

virsh destory  <虚拟机名称> #强制断电

virsh reboot <虚拟机名称>   #重启

virsh suspent <虚拟机名称>  #挂起

virsh resume <虚拟机名称>   #挂起的恢复

virsh undefine <虚拟机名称> #删除

virsh autostart <虚拟机名称> #随宿主机启动自动重启虚拟机

virsh autostart --disable <虚拟机名称> #随宿主机启动自动重启虚拟机的取消

virsh console <虚拟机名称> #串行控制台接入，无界面方式，但应该是独占模式

虚拟机配置相关

libvirt 的虚拟机配置存储在xml ，more存储为/etc/libvirt/qemu/

virsh dumpxml <虚拟机名称> #查此虚拟机的当前配置

virsh edit <虚拟机名称>  #编辑此虚拟机的配置

virsh dumpxml <虚拟机名称> backup.xml #导出配置

查看基本信息

virsh dominfo  <虚拟机名称> #查询基本摘要

virsh domiflist  <虚拟机名称> #查网卡信息

virsh domblklist  <虚拟机名称> #查硬盘信息

virsh vcpulnfo  <虚拟机名称>   #查vCPU信息

桩与玉

 和天博的玉站桩的发现，“苍玉礼天”，这种体验之前，一直认为这个是古人自己指定颜色指定材质后代表记号随便记录用的，但多次在这个西周的青玉壁前站桩后，真实的体会到这“天”应该是督脉之气，开始两次站桩都在10分钟左右，自己的整个后背感觉到很强的气感，从第二次超过10分钟后开始，两个肩胛下就开始有非常强向上顶的力，有几个瞬间都以为自己要长出翅膀了，后来感觉翅膀非常明显和整个后背浑然一体,从未感觉过的后背的开阔，身体的开阔，心的开阔。这个已经连续4次站桩 体验到，是可以重复的，现在自己过1个月左右就想去站站了：）。但这个应该和自己心的放松程有关系，中间有次和unu，吞一起去的天博，他们在体验vr，而我自己在玉器这边那次站就效果都不好，自己每次出去和unu在一起都不是很放松，想来是这个原因。

“黄玉礼地”那个青玉壁右侧90度的位置就是一个西周的琮，但是是青玉的，只是时间太久有红色的外部氧化层，这个站桩的感觉是十分强烈的任脉气感，从外阴到百汇的管子的感觉，稍微站久一点（5分钟以上）就感觉从两脚之间有一个很宽的烟囱道一直贯穿任脉冲出头顶，不停感觉到这个过程中，同时感觉自己的呼吸非常的深沉和厚。

另一个璧是西汉的比西周那个小，薄，但璧上有兽纹，这个是自己最先发现有气感的器，在它前站桩是感觉以膈为中心开阔，从神阙开始到膈不分身体的前后，整个中焦感觉都空了，非常舒服的空。这个不用站桩姿势太明显和时间长，在首次参观它时就感觉到了这个感觉，和它一起的有4，5个其他的青玉璧，这个是最明显的气感，但它比西周那个很不一样，感觉没有那个博大，这个空感觉自己是宇宙，那个空是自己这个宇宙的一部分，而西周那个，感觉自己是那个天气中的一个小部分。

另外还有是12月份去才留意到的新石器时代的青玉璧，比西周那个还厚，在离玻璃罩半步外就有气感，但当时时间急没有站，之后站了在详细记录。除了玉器，自己去了趟马可乐的家具博物馆，有两个黄花梨的桌子气感的浑厚度也非常明显，但因为之去了一次，没有太久的时间测试站桩效果，还是参观为主，但总体感觉最近1年自己在器和物，甚至是不同材质的地板上和不同空间的空气中感觉到的气也越来越明显的不同了，有时甚至感觉心境都受到这个影响，感觉自己在不同的气的场中穿梭，好神奇，之后好好体悟总结一下，我感觉自己有时可以通过手指，有时就是直接凭借皮肤就感觉到不同气，但前提都是自己要特别安静心特别空不紧张不忙碌才可以。

转:virsh 介绍

 virsh  是 libvirt 的命令行管理工具，用于管理 KVM/Xen/QEMU 虚拟化平台。它提供了对虚拟机生命周期管理的完整控制

基本介绍

virsh 是 libvirt 的命令行管理工具，用于管理 KVM/Xen/QEMU 虚拟化平台。它提供了对虚拟机生命周期管理的完整控制

安装

# Rocky/CentOS 8

sudo dnf install -y libvirt libvirt-client virt-install virt-viewer

命令说明

 virtio 是一个虚拟化 I/O 标准框架

# 作用：在宿主机和虚拟机之间提供高效的数据传输

# 优势：相比完全虚拟化（emulated）设备，性能提升 2-10 倍

modprobe virtio    #加载 virtio 核心模块，提供 virtio 框架的基础功能

modprobe virtio-pci #加载 virtio PCI 总线驱动，使 virtio 设备可以通过 PCI 总线与系统通信

modprobe virtio-blk #加载 virtio 块设备驱动，用于 virtio 虚拟磁盘

modprobe virtio-net #加载 virtio 网络设备驱动，用于 virtio 虚拟网卡。

 mark

介绍: 强制停用的服务，无法手动启用

屏蔽服务

systemctl mask <服务>

systemctl mask --now <服务> #屏蔽并关闭服务

解除屏蔽

systemctl unmask <服务>

systemctl unmask --now <服务> #解除并开启服务

转:linux 网桥配置

 

使用 Bridge网桥（最常用）

创建网桥，让多个容器通过网桥互联并访问外部网络。

bash

# 1. 创建网桥
sudo ip link add br0 type bridge
sudo ip link set br0 up
sudo ip addr add 192.168.100.1/24 dev br0

# 2. 创建veth pair
sudo ip link add veth-host type veth peer name veth-container

# 3. 将veth-host连接到网桥
sudo ip link set veth-host master br0
sudo ip link set veth-host up

# 4. 创建命名空间并移动veth-container
sudo ip netns add container1
sudo ip link set veth-container netns container1
sudo ip netns exec container1 ip link set veth-container up
sudo ip netns exec container1 ip addr add 192.168.100.100/24 dev veth-container

# 5. 启用NAT转发（让容器能访问外网）
sudo iptables -t nat -A POSTROUTING -s 192.168.100.0/24 ! -o br0 -j MASQUERADE
sudo sysctl -w net.ipv4.ip_forward=1

问题:Buff/Cache 中不可以算到Availabe中的部分是什么？

 交流中被问到free -h中为什么Available 比Buff/Cache小

查询发现Available估算时Buff/Cache有无法使用的部分，

是

Buff/Cache中不可立即回收（不能完全算入Available）的部分主要包括：

1. 脏页：已被修改但尚未写入磁盘的数据。

2. 正在被使用的页：有进程正在直接读取或写入的缓存页。

3. 被锁定在内存中的页：通过mlock()系统调用锁定的页。

4. 内核数据结构占用的Slab内存中的不可回收部分。

1. 脏页 - 最大的“不确定因素”

• 是什么：数据已在内存中被修改，但与磁盘上的版本不一致。内核必须先将它们写回磁盘，才能回收这些内存页。

• 影响：如果系统有大量写入操作（如数据库、日志写入），脏页会很多。回收它们需要等待I/O完成，因此不能立即提供给应用程序。

• 查看命令：

  bash

  grep -E 'Dirty|Writeback' /proc/meminfo

  输出示例：

  text

  Dirty:            12456 kB      # 待写回的脏数据量
  Writeback:          432 kB      # 正在写回的数据量

2. 正在被使用的页

• 是什么：某个进程正在通过read()或write()系统调用访问的缓存页。回收会导致进程I/O错误。

• 影响：通常比例很小，但存在。

3. 被锁定的页

• 是什么：通过mlock()系统调用明确要求常驻内存的页（如一些实时性要求高的应用、加密密钥）。

• 影响：明确不可回收。

4. Slab内存中的不可回收部分

• 是什么：/proc/meminfo中的SReclaimable（可回收Slab）被计入Buff/Cache，而SUnreclaim（不可回收Slab）则不被计入。

  • 可回收Slab：如目录项缓存（dentry）、索引节点缓存（inode_cache）。这些可被回收，并被计入Available。

  • 不可回收Slab：一些内核数据结构占用的内存，无法回收。

• 查看命令：

  bash

  grep -E 'SReclaimable|SUnreclaim' /proc/meminfo

---

内核如何计算 Available？（深入原理）

Available 的值在 /proc/meminfo 中是这样计算的（简化版）：

bash

# 查看精确值
grep Available /proc/meminfo

# 内核的估算逻辑（概念上）：
Available = Free + (PageCache的总和 - 其中不可立即回收的部分) + (SReclaimable * 权重系数)

不可立即回收的部分 主要通过以下方式估算：

1. 统计所有“干净”的页面（未修改的缓存），这些可以瞬间回收。

2. 估算回收“脏页”的成本，并根据系统当前压力、I/O负载等因素，决定将多大比例的脏页计入“可用”资源。在内存压力不大时，内核可能保守估计；压力大时，会更积极地将脏页的潜在回收能力计入。

---

一个具体的诊断例子

假设您的系统 free -h 显示：

text

              total        used        free      shared  buff/cache   available
Mem:            16Gi        10Gi       500Mi       1.0Gi        5.5Gi        4.5Gi

分析：

• buff/cache 有 5.5Gi

• available 有 4.5Gi

• free 只有 500Mi

计算 available 的来源：
4.5Gi ≈ 0.5Gi (free) + [5.5Gi (buff/cache) - 约 1.5Gi (不可立即回收部分)]

查看这“约1.5Gi”不可回收部分的具体构成：

bash

# 1. 查看脏页大小
cat /proc/meminfo | grep Dirty
# 假设输出 Dirty: 800000 kB (约0.76Gi)

# 2. 查看Slab分配
cat /proc/meminfo | grep -E 'SReclaimable|SUnreclaim'
# SReclaimable:  400000 kB  (约0.38Gi，这部分是buff/cache的一部分且可回收)
# SUnreclaim:    200000 kB  (约0.19Gi，这部分不属于buff/cache)

# 3. 粗略估算
# 不可立即回收部分 ≈ 脏页 + 其他难以估算的正在使用的页
# ≈ 0.76Gi + (0.5Gi ~ 0.7Gi) ≈ 1.3Gi ~ 1.5Gi

这个估算结果与上面的分析基本吻合。

结论与建议

1. Available 是一个智能估算值，而非简单加减。它告诉你在不引起严重I/O阻塞或进程错误的前提下，能安全分配多少内存。

2. Buff/Cache 和 Available 的差值，主要反映了脏页的数量和回收成本。

3. 当系统内存压力极大时，内核会启动激进的后台回写，将脏页刷入磁盘，从而将它们转变为“干净页”，增加 Available 的估算值。但这个过程会导致I/O争用，可能使系统变慢。

当您需要精确分析时，请使用 cat /proc/meminfo 获取原始数据，并重点关注 Dirty, Writeback, SReclaimable 这几个指标。它们正是 Buff/Cache 中那些“看得见但暂时用不了”的部分。