dd on macOS
Using dd
on macOS
- Unmount the disk before writing to it.
- Use
rdiskX
instead ofdiskX
for better performance. - Use Ctrl+T to show progress in
dd
.
1 | diskutil list |
我去,AI 帮写博客可太方便了,直接把内容写好了,连格式都不用我操心。连这句也是 AI 写的,哈哈哈。
dd
on macOSrdiskX
instead of diskX
for better performance.dd
.1 | diskutil list |
我去,AI 帮写博客可太方便了,直接把内容写好了,连格式都不用我操心。连这句也是 AI 写的,哈哈哈。
npm install 时报错 UNABLE_TO_GET_ISSUER_CERT_LOCALLY
使用 openssl s_client -brief -connect www.baidu.com:443 验证确实
openssl 使用的是 brew 安装的,brew 会自动创建软链接,但是有时候会出现软链接失效的情况,导致无法验证证书
通过 brew doctor 可以看到提示
1 | Warning: Broken symlinks were found. Remove them with `brew cleanup`: |
cert.pem 指向的是 ca-certificates 包中的证书,但是 ca-certificates 包也不完整,因为某种原因 cert.pem 文件丢失了
尝试重新安装 openssl 和 ca-certificates, 但是 reinstall 不行,需要 reinstall --force
brew doctor 验证 Your system is ready to brew.
再次使用 openssl s_client -brief -connect www.baidu.com:443 验证正常
npm install 也正常了
在 .tsx 文件中,coc.nvim 默认不会补全 html 标签,需要手动配置。
标签的补全是通过 coc-snippets 插件实现的
有两种方式
手动 :CocCommand snippets.addFiletypes html
或写入 vimrc 自动执行
1 | autocmd FileType typescriptreact CocCommand snippets.addFiletypes html |
使用 snippets.extends 可以在某种文件类型的基础上扩展另一种文件类型的补全
在 coc-config.json 中添加
1 | "snippets.extends": { |
从 PHP5 入了这个深坑以来已经有十多年,记录一些感觉有点东西的相关
写文的 Dec 2024,PHP 在 TIOBE 上的排行已经下降到 12 位,Dec 2023 时为 7
同时,Rust 的排行为 14 位,Dec 2023 时为 18
不过个人觉得 PHP 在 PHP8 这一代的进步是显著的,即有 JIT,也有注解,Match 表达式等新特性的加入
PHP 依旧充满活力!
Laravel 是优雅的 PHP Web 开发框架,优雅!太优雅了!
生态丰富,历史悠久,大多数情况下用它总没错!
早期吐槽 PHP 的主要问题之一就是性能,于是催生了以 C 语言写扩展的方法去做框架
YAF 的取名还是 Old fashioned 的 Yet Another XXX
比 YAF 提供了更多的功能
还维护了一个 Zephir language,用一个类似 PHP 语言的方式去写 PHP 扩展
Phalcon 的后期也是 Zephir/C 都有
Swoole 也是 C 扩展,基于异步事件驱动,为 PHP 引入了协程的概念,类似 Golang 的 goroutine
不过 Swoole 的团队真是一言难尽,搞出了下面这个操作后,逐步分离出来了 Open Swoole
Swoole’s admin interface hot-loads code from a third-party server ? · Issue #4434 · swoole/swoole-src
https://github.com/swoole/swoole-src/issues/4434
致力于使用最小 C 核心及多数 PHP 代码以支持 PHP 高性能网络编程
类似 Swoole
高性能、高灵活性的渐进式 PHP 协程框架,内置协程服务器及大量常用的组件
可基于 Swoole 或 Swow, 常驻内存,参考了 Laravel 的优雅
把 Laravel 架在 Swoole 上,以常驻内存的方式来加速其运行
纯 PHP 开发的开源高性能的 PHP 应用容器
靠多 Worker 进程,Epoll + 非阻塞 I/O
webman 是基于 workerman 的 HTTP 服务框架
追求性能的话,现在首推这两
PHP 在 8.1 加入了 Fibers,中文译为 纤程
纤,比线更细!
Fiber 主要用于为异步 I/O 实现协程,提供了独立栈分配、函数调用的暂停和恢复功能
就出自 AMPHP ext-fiber
投票结果以 50 对 14 通过
可以看到,PHP 创始人 Rasmus Lerdorf 和 Swoole 创始人韩天峰@matyhtf 均投了反对票
相较于 Swoole, Swow 等以 C 扩展的形式实现非阻塞 I/O,ReactPHP 是纯 PHP 的
从它对 PHP 版本的支持中可以看到,也是老牌且相当不容易了
fiber 之后,ReactPHP 也加入了对其的支持,提供了一个 Async Utilities
都为了非阻塞
把项目方便的打包成 PHAR
构建独立的 PHP 二进制文件包括 cli, fpm, micro 三种模式
其中 micro 又可与单文件或 phar 结合,把 PHP 项目也打包为一个文件
Cool!
Rust Crate
用 Rust 写 PHP 扩展的库
甚至还提供 Async futures,但依赖 PHP fibers, php-tokio 和 PHP Revolt event loop
与 AMPHP, PSL, ReactPHP 或其它 Base on Revolt 的异步 PHP 库兼容
Cool!
超详细
不用关机,直接编辑虚拟机硬件,把磁盘大小改大,如 100G => 120G
确定后,等进度条,一般很快就完成
vmware 层面就搞定了
OS 层面可能并未同步更新
可使用echo 1 > /sys/block/sda/device/rescan
触发一下
1 | fdisk -l |
由于是 AlmaLinux 9,这里我们并不使用 fdisk 进行分区调整,而是使用 parted
1 | parted -l |
此时的 pv 还未更新,使用pvresize
生效
1 | pvdisplay |
接着lvextend
你要扩容的 lv,通过df
查看挂载点对应的 lv,比如这里我们扩容 root
1 | df -hT |
这里直接再df
查看会发现 root 并未扩大,需要最 grow 一下生效,这里是 xfs 所以使用 xfs_growfs
1 | xfs_growfs /dev/almalinux_211/root |
打完收工
以 ChatGPT 为代表的各种大模型所展现出来的能力自不用说,但限于大模型的原理,AIGC 并不是真的懂了什么,它只是觉得这样回答会获得更高的认可
不过,只要能够找准场景,AIGC 还是帮助颇多
不想看文档?没问题,大模型就是干这个的!
Prompt: 我要给一台 H3C 的交换机,1/0/16 口配置 vlan20,请写出具体的配置脚本
ChatGPT:
以下是为 H3C 交换机配置 1/0/16 端口加入 VLAN 20 的具体配置脚本:
1 | system-view |
脚本说明:
system-view
: 进入全局配置模式。interface GigabitEthernet1/0/16
: 进入目标接口配置模式。port link-type access
: 将端口设置为 Access 模式(适合单一 VLAN)。port access vlan 20
: 指定该端口属于 VLAN 20。quit
: 退出接口配置模式。save
: 保存配置,使其在设备重启后生效。额外说明:
1 | vlan 20 |
遇到问题不知从何下手,让大模型帮你打开思路
但大模型也可能在这种时候,不懂装懂,所以最好再让它提供可验证的方法
Prompt: 公司有一颗 Aruba 的 AP 掉线了,AP 名称是 North-1,型号是 225,可能是什么原因,这些原因怎么验证
ChatGPT
Aruba AP 掉线可能由多种原因引起,以下是一些常见的原因和验证方法:
show interfaces
查看端口是否 UP)。North-1
AP 的状态。show log system
)以确认是否有 AP 掉线的记录。初步排查步骤:
如果问题仍未解决,可以提供 AP 日志或控制器日志,我们可以进一步分析问题。
Prompt 以下为某台 H3C 交换机的日志,请总结一下发生了什么
1 | %Oct 28 13:16:16:895 2024 IDC-12 OPTMOD/4/MODULE_IN: Ten-GigabitEthernet1/0/50: The transceiver is 10G_BASE_SR_SFP. |
ChatGPT
通过分析日志,可以总结以下事件:
光模块插入
Ten-GigabitEthernet1/0/50
,类型为 10G_BASE_SR_SFP
。链路状态变为 UP
up
。up
。Chassis ID
和 Port ID
均为 8cfd-18fd-fee5
。链路异常波动(短暂掉线并恢复)
down
。up
。以上这些场景,还可以通过精心构造 Prompt engineering,把输出变成格式化的,可执行的命令,借由系统自动的到环境中验证,再返回结果,多轮 Prompt,直到发现原因或问题恢复。也算是某种 Agent 吧
时间序列算法有很多,我们对如 cpu_usage, mem_usage, if_in, if_out 这些数据的关心点主要有两个,周期性和趋势
园区网的一些时序是有明显周期性的,如出口流量,流量的主要用户是人,人有日常作息。当我们强调周期性,忽略趋势时,就可以得到一个随时间变化的、动态的、上下限阈值。这样的阈值能够发现不寻常的事情,相对固定的一个上限值更有信息量
当我们同时考虑周期性和趋势时,就可以做容量预警了。你的磁盘可能将会在 X 天后占满,请及时处理。相比于针对用量的阈值,从剩余天数的维度去做提醒使得问题的处理可以更加从容,甚至防范于未然
如果硬件没有故障,配置也没有变更,那遇到的问题大概率会与容量或用量相关
相对于用量,知晓容量从而得其利用的百分比,在实践中更为有用。单纯的用量往往无法直观的评价现状。一台服务器的内存占用了 8G,如何判断占用得多不多,服务器运行得还正不正常,自然是要知晓内存的总大小
实践中,并不是所有容量都像内存这样可以容易的取到,一些只停留在纸面上(说明书、规格文档,虽然可能是 PDF),另一些只能靠人工填一个,甚至估一个
关注容量与用量不仅仅在故障判断上有作用,其与分类系统(如标签)结合,还能发挥管理意义上的统计作用,如
下面总结一些常用的容量
自不必多说,实践中需要注意的有
这里可以区分一下经典网络设备的 CPU 内存,与经典服务器的 CPU 内存
运维软件服务的是运维人员,管好 IT 资源也是为了给用户更好的信息化体验
H 所面对的客户,目前有这样一些困境
我们把软件的使用者分为三类,希望能够站在不同的角度去思考功能设计
关键词: 知识 经验
网在心中,手拿把掐。不一定是部门的领导,但是技术绝对的大头
运维软件要想能落地,转起来,首先要去讨好这些人,取得他们的信赖,哄着他们把心中的网,记录到系统中,即所谓的 CMDB
还有要管好 IT 资源所需要的经验和知识,不仅限于知识库,还有结合自身情况,适应部门运行的各种细化的设置
这些信息记在心中,停留在纸上,都没有录入系统能发挥更大的价值。信网中心,人来人往,唯有电子化、信息化才能最大限度的共享信息,分享价值。信息化中心自身的信息化,本就该是其它部门的标杆模范
这样的管理员是行业中的中流砥柱,与他们站在一起,倾听他们的需求,是好的运维软件替客户着想,为客户分忧的前提
在这些信息的收集上,真应该向游戏学习。你做对了什么,立刻就给正反馈,引导用户不断地按照游戏策划设想的那样去玩这个游戏。反观运维软件,又想从管理员那些套取大量信息,又没有明确及时的正反馈,这软件怎么能落地?怎么能真正在运维工作中发挥作用呢?怎么能产生用户粘性呢?
关键词: 时间 绩效
虽说我们希望系统或软件替人去完成那些简单、机械、重复、低价值的工作,但诸如设备上下架、布线、出现场等还是要人工的。运维软件的价值,就是把系统先把能做的都做了,然后再所谓的 人在回路
H 倾向于在真正干活的时候,系统提供一个工作台看板。这类似游戏中的任务板,任务板上没有任务,或者看板中一片绿,说明万事大吉,我可以继续摸鱼。任务板上有任务了,那我就开始干活
任务也应该是由系统判断后,精心处理且分门别类的呈现在工作台上。每一种分类的任务不能太多,会给人一种虱子多了不痒,债多了不愁的懈怠感。H 见了太多的客户,告警列表里躺着几百几千条,从最近到一年前发生的,未处理未恢复的告警。
可能分类有
统一处理带来方便考核
分类带来知识积累、效率与专精
关键词: 容量 业绩
领导从宏观的角度看问题,自然可以看成是各种模拟经营类游戏的玩家。试想,哪个模拟经营类游戏没有几个面板,告诉玩家你的资源现在有多少,用了多少,运行得多平稳高效,达到了多大规模,服务了多少用户,助力了多少发展,(击败了百分之多少的同行)。系统就应该提供这些情绪价值
2014 - 2024 作者 H 入职一家 IT 运维软件开发公司十年来,对 ITMS 的一些想法
主要工作对象为高校的园区网、数据中心等 IT 基础设施
想法很多、很杂,先记录下来,有空慢慢整理、归类、迭代
设想,理想情况下如果一个网络,硬件没变过,配置也没变过,那么这个网络只要今天是好的,那么明天肯定也是好的
虽然现实中有更多的意外会发生,如断电、断线、被偷等等,但配置管理应该是 ITMS 中的重要一环
硬件确定了,配置确定了,那么这个网络就确定了,网络的功能和行为都确定了
CaC 配置即代码
借鉴代码管理中应用最广的 git 版本管理的经验,网络的配置也有必要这么管理
我们不妨来对应一下
除了版本管理之外,在代码管理方面的成熟经验也很有启发
汇总一些用过的 keepalived 问题的排查方法
1 | kill -USR2 $(cat /var/run/keepalived.pid) |
向 keepalived 进程发 signal,其它可用的参考man keepalived
1 | HUP or SIGFUNC=RELOAD |
默认会生成/tmp/keepalived.stats
,包含各 Instance 的统计信息
1 | VRRP Instance: VI_0 |
1 | snmpwalk -v2c -cpublic 127.0.0.1 -mALL .1.3.6.1.4.1.9586 |
利用 SNMP 查询,结果包含当前状态和一些配置
1 | KEEPALIVED-MIB::version.0 = STRING: Keepalived v2.0.20 (01/22,2020) |
一般来说,就以往遇到的问题,往往都是 VRRP 包的收发不对劲,所以可以通过 tcpdump 抓包查看
同时结合 keepalived 的配置,关注抓包的网口,进出方向,vrid, prio
1 | tcpdump -i any -n vrrp and inbound |