Phoenix's island Sun will shine on the horizon. 2024-04-21T05:20:13.574Z https://blog.phoenixlzx.com/ Phoenix Nemo Hexo 通过重写 EEPROM 永久修改 MAC 地址 https://blog.phoenixlzx.com/2024/04/21/permanently-change-mac-eeprom/ 2024-04-21T04:54:29.000Z 2024-04-21T05:20:13.574Z 起因是装好一台服务器发现莫名其妙丢包 50%，并且同时另外一台机器也出现了这个问题。仔细观察发现是两台机器的 X520 网卡居然有一样的 MAC 地址…!!!

总之发现了问题就来粗暴地解决一下吧。要修改 MAC 地址有很多方法，但是两块 NIC 出厂时就有一样的 MAC 地址，那还是永久修改比较合适，免得后续出问题。

首先安装 ethtool 和 pciutils。

获取设备 ID，在这里也就是 EEPROM 的 magic header。其他厂商可能会有所不同。

1
2
3
~> lspci -nn
02:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
02:00.1 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

Intel 的 Vendor ID 是 8086，Device ID 在这里是 10fb。如果是 BSD 系统，也可以用 pciconf -lv 来读取 chip= 值。总之要用的 magic header 就是 0x10fb8086 啦。

然后来备份 EEPROM 以免搞砸。

1
~> ethtool -e ens1f0 raw on > eeprom-backup-ens1f0.bin

定位 MAC 地址

1
2
3
~> ethtool -e ens1f0 | grep '90 e2 xx xx xx'
0x0360:         90 e2 xx xx xx xx ...
0x0370:         90 e2 xx xx xx xx ...

完整的 MAC 地址就是

1
2
3
4
~> ethtool -e ens1f0 offset 0x0360 length 6
Offset          Values
------          ------
0x0360:         90 e2 xx xx xx c0

于是可以把最后两位修改一下：

1
2
~> ethtool -E ens1f0 magic 0x10fb8086 offset 0x0365 value 0xc2
~> ethtool -E ens1f0 magic 0x10fb8086 offset 0x0375 value 0xc3

修改完成后不会立即生效，需要拔插一下 NIC。系统里也可以实现，直接重载一下内核模块：

1
~> modprobe -r ixgbe

于是就生效啦：

1
2
3
4
~> ip l
6: ens1f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 90:e2:xx:xx:xx:c2 brd ff:ff:ff:ff:ff:ff
    altname enp2s0f0

丢包的问题也就消失了。

顺便吐槽：这种几率的事情落在我头上是不是可以去买彩票了？¯_(ツ)_/¯

]]> <p>起因是装好一台服务器发现莫名其妙丢包 50%，并且同时另外一台机器也出现了这个问题。仔细观察发现是两台机器的 X520 网卡居然有一样的 MAC 地址…!!!</p> AMI 主板 IPMI Bonding with ipmitool https://blog.phoenixlzx.com/2023/10/08/ipmitool-bonding-note/ 2023-10-08T08:00:33.000Z 2023-10-08T08:05:40.847Z 每日笔记时间。

这东西甚至没有文档。

于是折腾多了一些奇奇怪怪的 AMI 主板之后发现这货的 IPMI 居然有多个端口而且要 bonding。

虽然完全不懂他们为何要做这么脑残的设计，总之直接操作 ipmitool 配置的 IP 不生效，只能在访问不到 IPMI GUI 的情况下组 bonding 了。

启用 bonding

1
2
~> ipmitool raw 0x32 0x71 6 0 3
~> ipmitool raw 0x32 0x71 0x1 0x1 0x0 0x1 0x64 0x0 0x3 0x1

另外：禁用 bonding 是

1
~> ipmitool raw 0x32 0x71 0x1 0x0 0x0 0x1 0x64 0x0 0x3 0x1

然后检查状态，执行

1
~> ipmitool raw 0x32 0x72 0x1 0x0 0x0

如果返回 00 00 01 64 00 03 01 则为禁用，01 00 01 64 00 03 01 则是启用。

然后正常配置 lan 参数就可以了。

顺便再臭骂 AMI 不干人事。

]]> <p>每日笔记时间。</p> <p>这东西甚至没有文档。</p> 远程转换 H330 为 HBA330 https://blog.phoenixlzx.com/2023/06/27/remote-flash-h330-to-hba/ 2023-06-26T15:51:33.000Z 2023-06-26T16:39:46.967Z 由于 PERC H330 的 passthrough mode 并不适用于 ZFS 所以只好强刷为 HBA330 啦。

注意！此方法不适用于 H730/H830 系列 RAID 卡，且 H730 卡支持直接转换为 HBA。

操作前先备份！操作前先备份！操作前先备份！重要的事情说三遍！！！

准备必要程序和固件

  1. DOS 版本 megacli.exe
  2. DOS 版本 megarec3.exe，sas3flsh.exe 和其他必要文件
  3. HBA330 固件

…

我不装了，这里有 Sleyk 大神准备好的文件包。

准备 FreeDOS 启动镜像

首先下载 FreeDOS 的 USB Lite 镜像，作为基础系统环境。当前版本 1.3 解压后给出 FD13LITE.img 文件。

扩容 img 镜像到 128M：

1
~> truncate -s 96M FD13LITE.img

扩展镜像的 FAT 分区

1
~> fatresize -n 1 -s max FD13LITE.img

挂载 img 镜像

1
2
3
4
5
~> udisksctl loop-setup -f FD13LITE.img
Mapped file FD13LITE.img as /dev/loop0.
~> udisksctl mount -b /dev/loop0p1
Mounted /dev/loop0p1 at /run/media/user/FD13-LITE
~> cp /path/to/flash/files /run/media/user/FD13-LITE/

注意 DOS 并不能识别部分文件名，如果不修改的话，在 DOS 中会显示成类似 HBA~1 的形式。

复制好文件后卸载镜像

1
2
3
~> udisksctl unmount -b /dev/loop0p1
Unmounted /dev/loop0p1.
~> udisksctl loop-delete -b /dev/loop0

完事儿后把修改版 FD13LITE.img 远程挂载到 iDRAC KVM 里，然后重启服务器，从 Virtual Floppy 启动即可。

  • 注意：如果 Virtual Floppy 选项没有识别为 [Hard Disk] Virtual Floppy 的话则可能需要再次重启，因为镜像没有正确识别，无法进入 FreeDOS。具体原因不明。

Crossflash!

进入 FreeDOS 环境后会提示是否安装，选 No 回到 FreeDOS 就可以执行命令啦。

  1. 刷入 SMC3018 ROM
1
> megacli -adpfwflash -f smc3108.rom -noverchk -a0

然后因为是远程挂载镜像，会报一堆写入错误，需要一直忽略这些错误。一直等待操作完成报告成功。

  1. 重启，然后耐心等待直到出现 Baseport not responding. No adapter available 再进入 FreeDOS 环境。

  2. 清零 Serial Boot ROM (SBR)

1
> megarec3 -writesbr 0 sbrempty.bin

过程中的报错可以忽略，最终报告成功即可。

  1. 清零 flash
1
> megarec3 -cleanflash 0

  1. 重启。

  2. 再次进入 FreeDOS 环境，刷入 HBA330 固件。

1
> sas3flsh -o -f hba330.fw -b mptx64.rom

如果是 H330Mini，则需要刷 hba330mini.fw，否则会不识别硬盘。

  1. 最后一步，重编程 SAS 地址。看起来可以省略，默认是 16 个 0。
1
> sas3flsh -o -sasadd 0000000000000000

只能用数字和字母，必须 16 位。可以自己造也可以用原本的地址（megacli -adpallinfo -a0）。如果自己造的话需要保证不和同系统内的其他卡冲突。

完成

好耶！(≧∇≦)/

参考：

  1. https://sandelinos.com/nerd-stuff/Creating_customized_FreeDOS_images/
  2. https://forums.servethehome.com/index.php?threads/flash-crossflash-dell-h330-raid-card-to-hba330-12gbps-hba-it-firmware.25498/

顺便还折腾了一台老 HPE 的 P420i，步骤很简单，只需要官方的 ssacli 即可。

1
2
3
4
# 清空所有逻辑磁盘
~> ssacli controller slot=0 logicaldrive all delete forced
# 设置为 HBA Mode
~> ssacli controller slot=0 modify hbamode=on forced

如果不知道 slot 编号，可以 ssacli ctrl all show 来看。

但！是！

虽然改成了 HBA，但你不能从这 HBA 的硬盘启动。

(╯°□°）╯︵ ┻━┻

]]> <p>由于 PERC H330 的 passthrough mode 并不适用于 ZFS 所以只好强刷为 HBA330 啦。</p> 修复 CentOS 'org.freedesktop.login1' timed out https://blog.phoenixlzx.com/2022/06/06/rescue-broken-centos-systemd-timeout/ 2022-06-06T02:32:33.000Z 2022-06-06T03:22:08.295Z 又到了喜闻乐见帮人修系统的时间。

根据情况描述是 “stuck at ‘Starting switch root’”，初步判定是 initramfs 坏掉了。经过询问果不其然，某个特别爱没事儿就更新的家伙在更新的时候被数据中心的智障远程手按了电源¯(ツ)/¯

既然启动不能那就进 Rescue 呗。虽然 CentOS 这系统不怎么样，但是至少也算在原版 ISO 就提供了 Rescue 的选项，还能自动寻找根分区挂载。本来以为小事一桩，准备 chroot 的时候突然冒出来一句 “chroot: cannot run command `/bin/sh’: Exec format error” 就瞬间心里一顿$#%#$^$#@#%#

一般来讲，报错 “Exec format error” 代表二进制格式错误，例如在 32 位系统中执行 64 位二进制文件。但这不可能，首先同样是 x86_64 架构，安装的系统和 ISO 的系统也是同样的版本，磁盘也没有报错，为什么会出现这种问题？

更新时断电导致文件被写坏的可能性并不是没有，但奇怪的是执行 /bin/bash 也报一样的错误。能坏到这种程度怕不是 glibc 挂了…？但总之第一步是要能先进系统瞧瞧究竟，于是心一横，直接用 Live CD 的 /usr 覆盖磁盘上的对应目录。

1
~> cp -r /usr /mnt/sysimage/

然后再 chroot，果然成功进入系统，yum 命令也可以用了。既然是更新过程中断电，那应该先尝试修复未完成的更新。

1
2
3
4
~> yum-complete-transaction
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
No unfinished transactions left.

啊咧。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
~> yum update
--> Finished Dependency Resolution
Error:  Multilib version problems found. This often means that the root
       cause is something else and multilib version checking is just
       pointing out that there is a problem. Eg.:

         1. You have an upgrade for libselinux which is missing some
            dependency that another package requires. Yum is trying to
            solve this by installing an older version of glibc of the
            different architecture. If you exclude the bad architecture
            yum will tell you what the root cause is (which package
            requires what). You can try redoing the upgrade with
            --exclude glibc.otherarch ... this should give you an error
            message showing the root cause of the problem.

         2. You have multiple architectures of glibc installed, but
            yum can only see an upgrade for one of those arcitectures.
            If you don't want/need both architectures anymore then you
            can remove the one with the missing update and everything
            will work.

         3. You have duplicate versions of glibc installed already.
            You can use "yum check" to get yum show these errors.

       ...you can also use --setopt=protected_multilib=false to remove
       this checking, however this is almost never the correct thing to
       do as something else is very likely to go wrong (often causing
       much more problems).

       Protected multilib versions: glibc..... != glibc.....
       kbd... x86_64 != kbd ... x86_64

…还真是。

进一步了解到这个系统并没有安装 32 位包，那么这个 32 位的 glibc 是哪儿来的呢？yum check 无果，更何况还有一个奇怪的 kbd 包甚至跟 32 位毫无关系。看来坏的不轻，但是既然确定系统中没有 32 位包，那么可以继续莽到底了。

1
2
3
4
5
6
7
# 完成所有未更新的包
~> yum update --setopt=protected_multilib=false
# 为重装系统做准备
~> mkdir /root/tmp
~> cd /root/tmp
# 重装所有包
~> yum reinstall * --setopt=protected_multilib=false

一通操作猛如虎，第一次重装所有包时还会报错 ldconfig 一些库是空文件，第二次完整重装就看不到报错了。看来可行，果断重启，一堆 OK 之后看到了 login 提示。

1
2
3
4
5
6
7
8
localhost login: root

Login incorrect

Login incorrect


Login incorrect

嗯嗯嗯？？？我还没输入密码呢？？？

还没输入密码就报错，至少不是 PAM 的问题。在那之前呢？应该是 systemd-logind 了。幸运的是网络可以正常启动，SSH 能够正常登入系统。如果网络或者 SSH 也不行，那就只好再次进 rescue 了。

系统里很多本来应该有的底层服务没有启动，例如 systemd-logind。想查看这货的状态，结果报错：

1
Failed to activate service 'org.freedesktop.systemd1': timed out

咦？systemd 自己都没正常启动，看看日志：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
...
localhost dbus-daemon[1166]: Encountered error 'Error in file /etc/dbus-1/system.d/org.freedesktop.hostname1.conf, line 1, column 0: no element found
                                                  ' while parsing '/etc/dbus-1/system.d/org.freedesktop.hostname1.conf'
localhost dbus-daemon[1166]: Encountered error 'Error in file /etc/dbus-1/system.d/org.freedesktop.import1.conf, line 1, column 0: no element found
                                                  ' while parsing '/etc/dbus-1/system.d/org.freedesktop.import1.conf'
localhost dbus-daemon[1166]: Encountered error 'Error in file /etc/dbus-1/system.d/org.freedesktop.locale1.conf, line 1, column 0: no element found
                                                  ' while parsing '/etc/dbus-1/system.d/org.freedesktop.locale1.conf'
localhost dbus-daemon[1166]: Encountered error 'Error in file /etc/dbus-1/system.d/org.freedesktop.login1.conf, line 1, column 0: no element found
                                                  ' while parsing '/etc/dbus-1/system.d/org.freedesktop.login1.conf'
localhost dbus-daemon[1166]: Encountered error 'Error in file /etc/dbus-1/system.d/org.freedesktop.machine1.conf, line 1, column 0: no element found
                                                  ' while parsing '/etc/dbus-1/system.d/org.freedesktop.machine1.conf'
localhost dbus-daemon[1166]: Encountered error 'Error in file /etc/dbus-1/system.d/org.freedesktop.systemd1.conf, line 1, column 0: no element found
                                                  ' while parsing '/etc/dbus-1/system.d/org.freedesktop.systemd1.conf'
localhost dbus-daemon[1166]: Encountered error 'Error in file /etc/dbus-1/system.d/org.freedesktop.timedate1.conf, line 1, column 0: no element found
                                                  ' while parsing '/etc/dbus-1/system.d/org.freedesktop.timedate1.conf'
...

病的不轻。这些文件内容消失了，重装包并不会覆盖它们。只好手动来覆盖了。

1
2
3
4
5
6
7
# 安装必要工具
~> yum install yum-utils rpm2cpio
# 获取并解包 rpm
~> cd /root/tmp
~> yumdownloader dbus systemd
~> rpm2cpio dbus-1.10.24-15.el7.x86_64.rpm | cpio -idmv
~> rpm2cpio systemd-219-78.el7_9.5.x86_64.rpm | cpio -idmv

于是得到了这些包的内容。手动将 etc/dbus-1 目录下的所有文件覆盖到文件系统，然后执行 kill 1

1
2
3
4
5
6
7
localhost systemd[1]: Received SIGTERM from PID 4332 (bash).
localhost systemd[1]: Reexecuting.
localhost systemd[1]: systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ
localhost systemd[1]: Detected architecture x86-64.
localhost dbus[1166]: [system] Successfully activated service 'org.freedesktop.systemd1'
localhost systemd[1]: Started Login Service.
localhost systemd-logind[4723]: New seat seat0.

仔细检查一遍，各种服务都在正常启动了！

(๑•̀ㅂ•́)و✧

后记：别没事儿更新生产用系统。

后记 2：西方国家的数据中心远程手没有一个靠谱的。

]]> <p>又到了喜闻乐见帮人修系统的时间。</p> 配置 Fail2ban 保护 Proxmox VE https://blog.phoenixlzx.com/2021/12/02/protect-proxmox-ve-with-fail2ban/ 2021-12-02T13:40:32.000Z 2023-10-08T10:42:37.107Z 各种情况下 Proxmox VE 的登陆界面需要暴露在公网的时候，需要使用 fail2ban 来保护它不被暴力破解。

创建 filter

文件 /etc/fail2ban/filter.d/proxmox.conf

1
2
3
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =

创建 jail

文件 /etc/fail2ban/jail.d/proxmox.conf

1
2
3
4
5
6
7
8
[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
logpath = /var/log/daemon.log
maxretry = 3
# 1 hour
bantime = 3600

重启 fail2ban

1
~> systemctl restart fail2ban

然后检查是否配置生效

1
2
3
4
~> fail2ban-client status
Status
|- Number of jail:      2
`- Jail list:   proxmox, sshd

更新 PVE 8

由于 Debian 12 的 SSH 和 pveproxy 都使用 systemd 管理日志，可以直接编辑文件 /etc/fail2ban/jail.d/defaults-debian.conf 在最前面加入

1
2
3
4
5
6
7
8
9
10
[DEFAULT]
# Debian 12 has no log files, just journalctl
backend = systemd

# "bantime" is the number of seconds that a host is banned.
bantime  = 1d
# "maxretry" is the number of failures before a host get banned.
maxretry = 5
# A host is banned if it has generated "maxretry" during the last "findtime"
findtime  = 1h

然后移除 /etc/fail2ban/jail.d/proxmox.conf 中的 logpath 行。

]]> <p>各种情况下 Proxmox VE 的登陆界面需要暴露在公网的时候，需要使用 fail2ban 来保护它不被暴力破解。</p> 笔记：Arch Linux iPXE 基本启动脚本 https://blog.phoenixlzx.com/2021/11/09/basic-ipxe-boot-archlinux/ 2021-11-08T18:54:29.000Z 2021-11-08T19:16:50.209Z 似乎一直没有（公开且版本够新）的 Arch Linux 无人值守安装配置，所以想做一个。

参考 netboot.xyz 的 iPXE 配置，简单记录一下：

1
2
3
4
5
6
7
#!ipxe

set mirror http://archlinux.mirror/archlinux/iso/latest
set script http://unattended.install.script/script.sh
kernel ${mirror}/arch/boot/x86_64/vmlinuz-linux archisobasedir=arch archiso_http_srv=${mirror}/ ip=::: BOOTIF= net.ifnames=0 script=${script} mirror=auto
initrd ${base-url}/arch/boot/x86_64/initramfs-linux.img
boot

参考 SYSLINUX 的 PXELINUX 部分和内核 ipconfig 部分的文档写 ip= 参数的时候一边拿不到 DNS 一边疯狂报过多参数，最后发现是这个 bug 的锅。而且它还被 netboot.xyz 在脚本里注释出来了我可能需要去检查一下视力。

总之目前暂且只能用 DHCP 来在启动过程正确配置网络，否则无法下载系统镜像。

截至写这篇的 Arch Linux 的官方说明在这里。

最后就是自动安装脚本了，这个坑暂且撂在这里，以后有时间了再慢慢填…

咕咕咕

]]> <p>似乎一直没有（公开且版本够新）的 Arch Linux 无人值守安装配置，所以想做一个。</p> <p>参考 netboot.xyz 的 iPXE 配置，简单记录一下：</p> <figure class="highlight awk"><table><tr><td cla 修复 LVM XFS 的 Input/output error https://blog.phoenixlzx.com/2021/07/07/fix-lvm-xfs-input-output-error/ 2021-07-07T14:51:19.000Z 2021-07-07T15:05:31.610Z 某服务挂了。

设备被强制重启之后发现 LVM 满了，但是文件无法访问，所有文件操作显示 Input/output error。

查看 dmesg 发现大量文件系统错误，应该是磁盘写满后仍有进程不断读写的过程中被强制断电的结果。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[ 1714.217864] XFS (dm-0): page discard on page 00000000161e11d5, inode 0xd861b703d, offset 937984.
[ 1714.219674] XFS (dm-0): page discard on page 000000001d433e5e, inode 0xd861b703d, offset 942080.
[ 1714.221132] XFS (dm-0): page discard on page 00000000820efe8d, inode 0xd861b703d, offset 946176.
[ 1714.222431] XFS (dm-0): page discard on page 00000000518c8216, inode 0xd861b703d, offset 950272.
[ 1714.223744] XFS (dm-0): page discard on page 00000000753db760, inode 0xd861b703d, offset 954368.
[ 1714.225041] XFS (dm-0): page discard on page 00000000da40787d, inode 0xd861b703d, offset 958464.
[ 1714.226341] XFS (dm-0): page discard on page 00000000ba8adb4b, inode 0xd861b703d, offset 962560.
[ 1714.227629] XFS (dm-0): page discard on page 00000000784c4724, inode 0xd861b703d, offset 966656.
[ 1714.228923] XFS (dm-0): page discard on page 0000000063b2c764, inode 0xd861b703d, offset 970752.
[ 1714.228990] XFS (dm-0): page discard on page 0000000046a36fd8, inode 0xd861b703d, offset 974848.
[ 1714.337426] dm-0: writeback error on inode 58084519997, offset 905216, sector 34365282240
[ 1716.586318] dm-0: writeback error on inode 58084519997, offset 905216, sector 34365309816
[ 1728.444718] xfs_discard_page: 9674 callbacks suppressed

...

[ 1763.990454] XFS (dm-0): xfs_do_force_shutdown(0x8) called from line 955 of file fs/xfs/xfs_trans.c. Return address = 00000000ea9478e4
[ 1763.990459] XFS (dm-0): Corruption of in-memory data detected.  Shutting down filesystem
[ 1763.992696] XFS (dm-0): Please unmount the filesystem and rectify the problem(s)

日志写的很清楚了，那就来卸载修复吧

1
2
~> umount /data
~> xfs_repair /dev/mapper/data

显示

1
2
3
4
5
6
7
8
9
10
Phase 1 - find and verify superblock...
        - reporting progress in intervals of 15 minutes
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

咦，为什么还要我 remount。

1
2
3
~> mount -a
~> umount /data
~> xfs_repair /dev/mapper/data

然后就是漫长的等待…（因为是 HDD）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
Phase 1 - find and verify superblock...
        - reporting progress in intervals of 15 minutes
Phase 2 - using internal log
        - zero log...
        - 19:33:58: zeroing log - 521728 of 521728 blocks done
        - scan filesystem freespace and inode maps...
        - 19:34:11: scanning filesystem freespace - 33 of 33 allocation groups done
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - 19:34:11: scanning agi unlinked lists - 33 of 33 allocation groups done
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 15
        - agno = 30
        ...
        - agno = 27
        - agno = 28
        - agno = 29
        - 19:43:14: process known inodes and inode discovery - 16555072 of 16555072 inodes done
        - process newly discovered inodes...
        - 19:43:14: process newly discovered inodes - 33 of 33 allocation groups done
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - 19:43:15: setting up duplicate extent list - 33 of 33 allocation groups done
        - check for inodes claiming duplicate blocks...
        - agno = 7
        - agno = 3
        - agno = 8
        ...
        - agno = 30
        - agno = 31
        - agno = 32
        - 19:43:24: check for inodes claiming duplicate blocks - 16555072 of 16555072 inodes done
Phase 5 - rebuild AG headers and trees...
        - 19:43:27: rebuild AG headers and trees - 33 of 33 allocation groups done
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - 19:48:58: rebuild AG headers and trees - 33 of 33 allocation groups done
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
        - 19:50:02: verify and correct link counts - 33 of 33 allocation groups done
done

完事后重启，就可以重新访问 LVM 里的文件啦。

后记：

这次所幸根分区是单独的盘，如果根分区和 LVM 在同一块物理盘上的话，需要重启系统进入救援模式，手动激活 LVM 再执行修复。

以及 XFS 还是靠谱呀（看向某每天摸鱼看番剧透的 btrfs 开发者

]]> <p>某服务挂了。</p> <p>设备被强制重启之后发现 LVM 满了，但是文件无法访问，所有文件操作显示 <code>Input/output error</code>。</p> FAT32 与 FAT32 的不同 https://blog.phoenixlzx.com/2021/04/12/difference-between-fat32/ 2021-04-12T06:45:05.000Z 2021-04-12T07:19:25.007Z 缘由：游戏用的台式机坏掉了。

去年底配了一台 ITX，GIGABYTE AORUS X570 I PRO WIFI 大概是这个型号的主板，在一次 BIOS 升级之后无法进入 POST，配件 LED 都显示正常，风扇正常。于是按照官方说明，准备重刷 BIOS：

  • 一张闪存盘格式化为 FAT32
  • 固件改名为 GIGABYTE.BIN 放在根目录下
  • 插在 BIOS USB 接口，接通电源但不开机的情况下按 Q Flash Plus 开始刷机

但是按下之后并没有描述的橙色灯亮，只看到闪存盘的存取 LED 快速闪了几下就没了动静。

一度以为文件有问题，或者闪存盘有问题，或者格式化有问题。于是拆了一个新的闪迪的闪存盘，重新下载保存固件，依然没有效果。

对着文档回顾一次操作顺序以免有疏漏，然后发现了蹊跷。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
~> sudo fdisk /dev/sdb
Welcome to fdisk (util-linux 2.36.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): o
Created a new DOS disklabel with disk identifier 0x5f576f17.

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-15137279, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-15137279, default 15137279):

Created a new partition 1 of type 'Linux' and of size 7.2 GiB.

Created a new partition 1 of type ‘Linux’ and of size 7.2 GiB.

嗯？

Partition Type 是 Linux。这会是读取失败的原因么？于是列出所有的文件系统

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Command (m for help): l

00 Empty            24 NEC DOS          81 Minix / old Lin  bf Solaris
01 FAT12            27 Hidden NTFS Win  82 Linux swap / So  c1 DRDOS/sec (FAT-
02 XENIX root       39 Plan 9           83 Linux            c4 DRDOS/sec (FAT-
03 XENIX usr        3c PartitionMagic   84 OS/2 hidden or   c6 DRDOS/sec (FAT-
04 FAT16 <32M       40 Venix 80286      85 Linux extended   c7 Syrinx
05 Extended         41 PPC PReP Boot    86 NTFS volume set  da Non-FS data
06 FAT16            42 SFS              87 NTFS volume set  db CP/M / CTOS / .
07 HPFS/NTFS/exFAT  4d QNX4.x           88 Linux plaintext  de Dell Utility
08 AIX              4e QNX4.x 2nd part  8e Linux LVM        df BootIt
09 AIX bootable     4f QNX4.x 3rd part  93 Amoeba           e1 DOS access
0a OS/2 Boot Manag  50 OnTrack DM       94 Amoeba BBT       e3 DOS R/O
0b W95 FAT32        51 OnTrack DM6 Aux  9f BSD/OS           e4 SpeedStor
0c W95 FAT32 (LBA)  52 CP/M             a0 IBM Thinkpad hi  ea Linux extended
0e W95 FAT16 (LBA)  53 OnTrack DM6 Aux  a5 FreeBSD          eb BeOS fs
0f W95 Ext'd (LBA)  54 OnTrackDM6       a6 OpenBSD          ee GPT
10 OPUS             55 EZ-Drive         a7 NeXTSTEP         ef EFI (FAT-12/16/
11 Hidden FAT12     56 Golden Bow       a8 Darwin UFS       f0 Linux/PA-RISC b
12 Compaq diagnost  5c Priam Edisk      a9 NetBSD           f1 SpeedStor
14 Hidden FAT16 <3  61 SpeedStor        ab Darwin boot      f4 SpeedStor
16 Hidden FAT16     63 GNU HURD or Sys  af HFS / HFS+       f2 DOS secondary
17 Hidden HPFS/NTF  64 Novell Netware   b7 BSDI fs          fb VMware VMFS
18 AST SmartSleep   65 Novell Netware   b8 BSDI swap        fc VMware VMKCORE
1b Hidden W95 FAT3  70 DiskSecure Mult  bb Boot Wizard hid  fd Linux raid auto
1c Hidden W95 FAT3  75 PC/IX            bc Acronis FAT32 L  fe LANstep
1e Hidden W95 FAT1  80 Old Minix        be Solaris boot     ff BBT

Aliases:
   linux          - 83
   swap           - 82
   extended       - 05
   uefi           - EF
   raid           - FD
   lvm            - 8E
   linuxex        - 85

好家伙，看到一个 0b W95 FAT32。直接把分区类型改为 0b 再重新格式化，放入文件，插回 BIOS USB 接口，按下 Q Flash Plus，瞬间电源启动，橙色 LED 开始闪烁，说明已经开始刷写。

查了 Wikipedia，看到这么一段话：

Lists of assigned partition types to be used in the partition table in the MBR were originally maintained by IBM and Microsoft internally. When the market of PC operating systems and disk tools grew and liberated, other vendors had a need to assign special partition types to their products as well. As Microsoft neither documented all partition types already assigned by them nor wanted to maintain foreign assignments, third parties started to simply assign partition types on their own behalf in a mostly uncoordinated trial-and-error manner. This led to various conflictive double-assignments sometimes causing severe compatibility problems between certain products.([1])[http://msdn.microsoft.com/en-us/windows/hardware/gg463525.aspx]

所以也就有了 Partition Type 这样一个细节导致刷写任务失败，原因是 GIGABYTE 在开发 Q Flash Plus 的时候没有考虑过不同厂家、设备、操作系统所建立的 FAT32 分区类型的不同，文档中也没有提及这个问题。顺带又看到了同样有很多 GIGABYTE 主板的用户在网络上表示他们没有办法通过这种方式刷写 BIOS，也难怪会让人困惑了。

再顺便，使用闪迪出厂自带的 FAT32 文件系统无法正常被 Q Flash Plus 识别，是不是也说明了闪迪的闪存盘在出厂时建立的文件系统类型并不是 0b W95 FAT32？

总之：

  1. 我的主板终于修好了。
  2. 开发任何功能时要考虑好对不同硬件、系统、环境的兼容性。
  3. 下次买主板，还是乖乖选败家之眼 ASUS ROG 吧（笑
]]> <p>缘由：游戏用的台式机坏掉了。</p> 在 Linux 系统中升级超微 BIOS 固件 https://blog.phoenixlzx.com/2021/02/03/update-supermicro-bios-to-avoid-2021-issue-in-linux/ 2021-02-03T01:33:17.000Z 2021-02-03T03:05:26.937Z 最近突然有客户找来说 BIOS 进不去了呀…看截图 stuck 在 POST Code AB 大概就知道什么情况了。

这不就是经典的 y2k bug 再现嘛…

一般情况下，升级超微 BIOS 固件的推荐方式是制作 DOS 启动盘引导系统升级，不过现在 BIOS 进不去也没有物理 access 就只好在 Linux 里操作啦。

获取设备信息

简单命令 lshw

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
~> lshw | head -n 25
localhost                  
    description: System
    product: X9SCL/X9SCM (To be filled by O.E.M.)
    vendor: Supermicro
    version: 0123456789
    serial: 0123456789
    width: 64 bits
    capabilities: smbios-2.7 dmi-2.7 smp vsyscall32
    configuration: boot=normal chassis=desktop family=To be filled by O.E.M. sku=To be filled by O.E.M. uuid=[redacted]
  *-core
       description: Motherboard
       product: X9SCL/X9SCM
       vendor: Supermicro
       physical id: 0
       version: 1.11A
       serial: [redacted]
       slot: To be filled by O.E.M.
     *-firmware
          description: BIOS
          vendor: American Megatrends Inc.
          physical id: 0
          version: 1.1a
          date: 09/28/2011
          size: 64KiB
          capacity: 8128KiB

X9 主板不是 2015 年就 EOL 了吗这可真是够老了…

总之主板型号是 X9SCM 于是在超微找到了新版的 BIOS 固件。下载到系统中解压得到一堆文件，其中 X9SCM1.106 这个文件就是需要的 BIOS 固件本体。

编译 SUM 内核模块

Supermicro Update Manager (SUM) 是用于在系统中控制 BIOS/BMC 的程序。首先下载并解压，得到 sum 二进制文件和一堆其他东西。在 driver 目录中发现了对应发行版预编译的内核模块，但是直接 insmod sum_bios.ko 出错，好在它也提供了源码，那么就直接编译吧。

首先安装对应内核的 Linux 头文件，搜索 linux-headers 一般都可以找到。

1
2
~> uname -a
Linux localhost 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux

然后

1
~> apt install linux-headers-4.19.0-13-amd64 build-essential # 还需要 make 和 gcc

进入 driver/Source/Linux 执行 make，如果成功编译，则 insmod ./sum_bios.ko。

嗯，这次没有报错了。

升级 BIOS

升级命令和其他主板商以及 RH 系的包命名风格一样喜欢大小写混合 = =…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
~> ./sum -c UpdateBios --file ../X9SCM1.106/X9SCM1.106
Supermicro Update Manager (for UEFI BIOS) 2.5.1 (2020/11/12) (x86_64)
Copyright(C) 2013-2020 Super Micro Computer, Inc. All rights reserved.

WARNING: BIOS setting will be reset without option --preserve_setting
Reading BIOS flash ..................... (100%)
Writing BIOS flash ..................... (100%)
Verifying BIOS flash ................... (100%)
Checking ME Firmware ...
Putting ME data to BIOS ................ (100%)
Writing ME region in BIOS flash ...
 - Update success for /FDT!!
 - Updated Recovery Loader to OPRx
 - Updated FPT, MFSB, FTPR and MFS
 - ME Entire Image done
WARNING:Must power cycle or restart the system for the changes to take effect!

至此就基本完成啦。然后直接重启即可生效。

不过还是需要注意一下，升级固件都是有变砖风险的，某些情况下需要先联系硬件厂商支持确定升级路线。

以及新版 X10 开始升级 BIOS 需要激活 license 了… 嘛。听说超微的密钥早就被提取出来写了算号器了（什

最后的最后，提醒各位到 2038 年只有 17 年了哦（笑

]]> <p>最近突然有客户找来说 BIOS 进不去了呀…看截图 stuck 在 POST Code AB 大概就知道什么情况了。</p> <p>这不就是经典的 y2k bug 再现嘛…</p> 软件工程实践上的一点思考 https://blog.phoenixlzx.com/2019/06/01/thoughts-on-software-engineering/ 2019-06-01T02:42:50.000Z 2020-09-14T04:20:19.886Z 曾经大学时对于软件工程这类理论课不屑一顾，认为这些课本都是只在大学里讲学而并不实际参与工程的教授写的东西。但是经过这些年从自己开发程序编写代码，到与公司团队同学、兴趣圈的朋友一起开发项目，也积累、总结了一些经验和教训。正巧昨晚在游戏建设里参与了这类讨论，于是记下一些思考免得忘记。

案例 1

命令方块是 Minecraft 里用于执行游戏命令、实现各种触发性或持续性功能的方块。在游戏地图中需要展示一些浮空的名称标签，便是用命令方块生成隐形盔甲架实现的。这些盔甲架参数复杂且需要在地图里很多特定位置生成，负责的同学便在每个生成的位置下面放了重新生成的命令方块，生成的坐标是相对坐标，因此写好标签的命令方块便可被无限复用。

由于盔甲架属于实体，而实体在 Minecraft 中被认为是不可靠的：有无数种可能这实体会被移动或被清除。
因此我的建议是：将这些命令方块全部放到控制室，坐标写成绝对坐标并加上统一标签，便可做到一键生成全部、一键清除全部。

该同学表示：不想写绝对坐标，因为很麻烦。

案例 2

由于游戏玩法的需要，编写了新的插件。几天后按照原计划应当可以准备第一次基本功能测试时，负责开发的同学表示只写了大约 1/4 的功能。进度很慢的原因是 Minecraft 的实现过于糟糕，而 Spigot 和 Paper 等修改版也没有很好封装 API 导致几乎所有的事件都需要手动处理。

接下来的协同开发中该同学又在反复尝试对配置文件中属性类似的部分使用同一个序列化/反序列化方法处理、对不同配置文件中的不同物品记录项也加上了一层包装来使得其能够被一个序列化/反序列化方法处理、在其他一些程序逻辑上也在尝试复用代码减少冗余度。

我说，你先专心把功能快速叠出来，然后再去想优化的事情。
这位同学表示不能接受，他认为代码应该从编写时就是整洁的。

论点：矫枉过正的代码复用

代码复用是很常见的代码结构优化方式。更少的代码冗余可以减少维护的复杂度，也降低出错的可能。

但是在案例 1 中，如此复用代码（放置同样的命令方块）却实际上造成了更多的冗余：如果要修改一个属性，就需要记录整个世界里每一个命令方块的位置，然后一个个去修改它。相反，由于游戏世界地图里的建筑几乎不可能变化（虽然现实需求很少会有这种条件），统一放在控制室、hard code
所有的坐标作为一个大方法调用，却是在这需求前提下的更好的实现方式。如果需要修改属性，可以只在一个地方修改所有的命令方块。

或者说，重复放置命令方块的过程，就是 copy’n’paste 冗余代码的过程。

而案例 2 则更具有代表性。在项目初期，是否应当关注代码质量？
我认为是应当关注的，但是这基于开发者的工程实践经验。优秀的、熟练的开发者应当在代码编写时就能灵活使用各种简单的优化手段减少初期的代码冗余，但是对于在校大学生没有足够的项目经验时，面对紧凑的项目时间安排应当集中更多精力实现功能。此时过分关注代码优化会被分心导致各种问题——例如这位同学编写的代码基本没有能够一次通过所有测试的情况，而且绝大多数的错误都看起来只是粗心，并不是不理解、写不出的问题。

论点：实现，调整，优化

“Make it work, make it right, make it fast.” – Kent Beck

这是很多软件工程推崇的敏捷开发指导方向。在案例 1 中，该同学只做了第一步——复用同样的、带有相对坐标的命令方块（方法）快速实现了所有的功能。但是从后续维护的角度来讲，这样的实现没有 make it right，更不用提 fast。

而在案例 2 中，这位同学将三个阶段在初期就全部揉进去，但是由于工程经验不足，在思考优化方案时花费了过多的精力，也导致了代码精度不够，反复修改也无法顺利通过测试。

从个人经验来看，前期的代码编写应注重功能实现，并在编码能力基础上直接编写清晰的代码结构。功能实现后，再根据需求和测试中的问题「重构」打磨细节、尝试更好的实现方式。这个过程不仅在完善整个程序，对自己的系统架构把握和设计经验也有很大的提升。最后一个阶段，则是针对性的优化少量代码使整个系统更加稳定、高效。

论点：架构的改动

这是一个比较小型的项目。需求和基本功能架构从一开始便已经讨论清楚。后续的调整不大，但是每当有少量的需求修改或架构微调，都导致了很大的代码变动。而按照这位同学的思路，每次改动都要重新思考代码结构，这浪费很多的时间。

从实际工程角度，需求变化并带来架构的微调甚至大改动都可以说是很常见的事情。在前期编码实现阶段如果揉入过多对于代码结构的过多考量，每次改动都可能会使这些思考的时间被浪费。因此，在前期编码时不应为架构考虑消耗过多的时间，而在重构过程中，由于已经完成基本的功能实现，且对已有代码还处在熟悉的热度，可以快速适配需要修改、调整的架构，并基于前期编码时的各种尝试和实验的结论选择最佳的实现方式。

以上是基于近期项目中的讨论，在软件工程层面上的思考。如有缺漏不当之处，欢迎指正。

]]> <p>曾经大学时对于软件工程这类理论课不屑一顾，认为这些课本都是只在大学里讲学而并不实际参与工程的教授写的东西。但是经过这些年从自己开发程序编写代码，到与公司团队同学、兴趣圈的朋友一起开发项目，也积累、总结了一些经验和教训。正巧昨晚在游戏建设里参与了这类讨论，于是记下一些思考免得忘记。</p> WireGuard 真香 https://blog.phoenixlzx.com/2019/05/07/get-started-with-wireguard/ 2019-05-06T17:13:49.000Z 2020-09-14T04:20:19.882Z 真是老了跟不上时代了，这么好的东西为什么我现在才开始用？？

其实这东西刚出来就在关注了不过确实前段时间才有机会尝试折腾一下。优点很多，也有无数人写过文章介绍，所以就不再多废话。主要看中它的 PtP 特性（服务器之间）和支持漫游（服务器-客户端）。当然目前在梯子方面的表现，即便是优秀的隧道方案，但由于折腾的人多了，面对万里城墙，这谁顶得住哇。

所以本文只讨论 WireGuard 作为访问企业网的隧道方案，算是初步折腾的笔记。

服务器配置

一个基本的 PtP 配置结构 /etc/wireguard/wg0.conf

1
2
3
4
5
6
7
8
9
[Interface]
Address = 10.0.0.1/32
PrivateKey = [CLIENT PRIVATE KEY]

[Peer]
PublicKey = [SERVER PUBLICKEY]
AllowedIPs = 10.0.0.0/24, 10.123.45.0/24, 1234:4567:89ab::/48
Endpoint = [SERVER ENDPOINT]:48574
PersistentKeepalive = 25

生成私钥

1
2
wg genkey > privatekey
chmod 600 privatekey

基于私钥生成本机的公钥

1
wg pubkey < privatekey > publickey

或者一步完成的操作

1
wg genkey | tee privatekey | wg pubkey > publickey

额外生成预共享密钥来进一步增强安全性

1
wg genpsk > preshared

这样服务器之间的互联配置就基本完成了。使用 wg-quick up <config> 来快速启动 WireGuard。

如果要配合客户端使用，则需要配置 NAT。顺便如果客户端没有 IPv6，也可以通过此法来给客户端提供 IPv6 Enablement。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[Interface]
Address = 10.200.200.1/24
Address = fd42:42:42::1/64
SaveConfig = true
ListenPort = 51820
PrivateKey = [SERVER PRIVATE KEY]

# note - substitute eth0 in the following lines to match the Internet-facing interface
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# client foo
PublicKey = [FOO's PUBLIC KEY]
PresharedKey = [PRE-SHARED KEY]
AllowedIPs = 10.200.200.2/32, fd42:42:42::2/128

[Peer]
# client bar
PublicKey = [BAR's PUBLIC KEY]
AllowedIPs = 10.200.200.3/32, fd42:42:42::3/128

在此例中需注意 Allowed IPs 不可 overlap 否则会造成包转发错误。

客户端

与上文中服务器配置相照应的客户端配置示例如下：

1
2
3
4
5
6
7
8
9
10
11
[Interface]
Address = 10.200.200.2/24
Address = fd42:42:42::2/64
PrivateKey = [FOO's PRIVATE KEY]
DNS = 1.1.1.1

[Peer]
PublicKey = [SERVER PUBLICKEY]
PresharedKey = [PRE-SHARED KEY]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = [SERVER PUBLIC IP ADDRESS]:51820

客户端的 AllowedIPs 如果使用 catch-all 0.0.0.0/0, ::/0 也就会默认转发所有的流量到服务器。该选项实际作用是路由表，控制哪些流量需要经由服务器转发。

配置完毕即可使用 wg-quick up <config> 启动 WireGuard。如果一切顺利，通过路由追踪应该可以看到流量已经交由服务器转发。

总结

由于工作需要，经常合上笔记本动身前往其他地方。在接入传统企业网例如 L2TP/IPSec 甚至 AnyConnect 都无法保证设备下次进入工作状态时可以立即恢复连接。而 WireGuard 在不同网络、不同地域、不同网络中断时间等各种情况下均可在下次进入网络覆盖时立即恢复连接，再也不必担心网络中断恢复时手忙脚乱配置隧道或者不小心泄密啦。

目前唯一的不足，大概就是还没有 Windows 客户端，没有办法推广到非技术部门（虽然影响不到我…

总之，真香.jpg

Reference:

[1] https://wiki.archlinux.org/index.php/WireGuard

]]> <p><del>真是老了跟不上时代了，这么好的东西为什么我现在才开始用？？</del></p> 制作 Arch Linux 内存系统启动盘 https://blog.phoenixlzx.com/2018/12/14/bootable-archlinux-in-memory-rescue-system/ 2018-12-14T03:58:39.000Z 2020-09-14T04:20:19.882Z 之前尝试过 Arch Linux in RAM 完全运行在内存中的轻量业务系统，最近在维护一些物理服务器看到没有安装系统的服务器不断重启，想到了可以制作类似的内存系统启动盘，以高效完成系统测试、安装、远程维护等任务。

这时候就要祭出 mkarchiso 大法了。这是自动化制作最新版 Arch Live 镜像的工具集，当然也可用于制作定制化的 Arch 镜像。

准备

首先安装 archiso 包

1
~> sudo pacman -Syy archiso

它提供了两种配置方案，一种是只包含基本系统的 baseline，一种是可以制作定制 ISO 的 releng。要制作维护用 ISO，当然是复制 releng 配置啦。

1
2
~> cp -r /usr/share/archiso/configs/releng/ archlive
~> cd archlive

定制

整个过程不要太简单。先来了解下各个文件的用途：

  • build.sh - 用于制作镜像的自动化脚本，可以在这里修改一些名称变量或制作过程的逻辑。
  • packages.x86_64 - 一份要安装的包列表，一行一个。
  • pacman.conf - pacman 的配置文件，不用多说了吧。
  • airootfs - Live 系统的 rootfs，除了安装的包之外，其他的定制（以及启动执行脚本等）都在这里。遵循 rootfs 的目录规则。
  • efiboot / syslinux / isolinux 用于设置 BIOS / EFI 启动的配置。

将 [archlinuxcn] 仓库加入 pacman.conf：

1
2
[archlinuxcn]
Server = https://cdn.repo.archlinuxcn.org/$arch

然后修改 packages.x86_64，加入 archlinuxcn-keyring 和其他需要预安装的包：

1
2
3
4
5
archlinuxcn-keyring
htop
iftop
iotop
ipmitool

按需修改即可啦。

要启动为内存系统，需要加启动参数 copytoram。

修改文件 syslinux/archiso_pxe.cfg 和 syslinux/archiso_sys.cfg 文件，在启动参数后加 copytoram，像这样：

1
2
3
4
5
6
7
8
9
10
11
INCLUDE boot/syslinux/archiso_head.cfg

LABEL arch64
TEXT HELP
Boot the Arch Linux (x86_64) live medium.
It allows you to install Arch Linux or perform system maintenance.
ENDTEXT
MENU LABEL Boot Arch Linux (x86_64)
LINUX boot/x86_64/vmlinuz
INITRD boot/intel_ucode.img,boot/amd_ucode.img,boot/x86_64/archiso.img
APPEND archisobasedir=%INSTALL_DIR% archisolabel=%ARCHISO_LABEL% copytoram

启动时即可将整个 SquashFS 文件复制到内存。如果内存比较小，也可以指定 copytoram_size 来限制 tmpfs 占用内存的最大数量。

同样，也需要修改 efiboot/loader/entries/archiso-x86_64-usb.conf 的启动参数。在 options 行添加

1
options archisobasedir=%INSTALL_DIR% archisolabel=%ARCHISO_LABEL% copytoram

制作

创建工作目录和输出目录

1
mkdir -p work out

最后一步，只需要以 root 权限执行 ./build.sh 就可以啦。

要看具体执行过程的话，加 -v。-h 看所有参数。

完成后，即可在 out 目录得到准备好的 ISO 文件。将其 dd 到 USB 闪存盘，大功告成(‘・ω・’)

Ref:

  1. https://wiki.archlinux.org/index.php/Archiso
  2. https://git.archlinux.org/archiso.git/tree/docs/README.bootparams#n53
]]> <p>之前尝试过 <a href="/2018/08/04/archlinux-ramroot-office-service-router/">Arch Linux in RAM</a> 完全运行在内存中的轻量业务系统，最近在维护一些物理服务器看到没有安装系统的服务器不断重启，想到了可以制作类似的内存系统启动盘，以高效完成系统测试、安装、远程维护等任务。</p> 使用 fs.WriteStream 编写超简单的日志流 https://blog.phoenixlzx.com/2018/11/18/super-easy-logger-with-writestream/ 2018-11-18T10:08:44.000Z 2020-09-14T04:20:19.882Z 虽然 console.log 很好用，但是生产环境需要保存日志的时候就比较蛋疼。暴力 fs.appendFile 会消耗大量的 file handler，因此用 writable stream 来复用 file handler 是更好的选择。

大概是个不能再简单的思路了。先创建一个写入流

1
2
3
const fs = require('fs');

let logStream = fs.createWriteStream('./test.log');

这样便创建了一个文件写入口，需要时直接调用 logStream.write 即可写入数据。
接下来编写一个用于记录日志的函数替代 console.log

1
2
3
function logger (message) {
    logStream.write(message);
}

至此基本功能就写完啦。但是太简陋了对不对，还是要再加点装饰。

重写 logger 函数，区分 stdout 和 stderr

1
2
3
4
5
6
7
8
9
10
11
12
let logInfo = fs.createWriteStream('./stdout.log');
let logError = fs.createWriteStream('./stderr.log');

let Logger = {};

Logger.info = (message) => {
    logInfo.write('[INFO] ' + message);
}

Logger.error = (message) => {
    logError.write('[ERROR] ' + message);
}

感觉还是少了点什么…日期？

1
2
3
Logger.info = (message) => {
    logInfo.write(new Date().toISOString() + ' [INFO] ' + message + '\n');
}

嗯嗯。这就像样了。把代码整合起来

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
const fs = require('fs');

let logInfo = fs.createWriteStream('./stdout.log');
let logError = fs.createWriteStream('./stderr.log');

let Logger = {};

Logger.info = (message) => {
    logInfo.write(new Date().toISOString() + ' [INFO] ' + message + '\n');
}
Logger.error = (message) => {
    logError.write(new Date().toISOString() + ' [ERROR] ' + message + '\n');    
}

module.exports = Logger;

需要用时

1
Logger.info('This is an information.');

现在看对应的 stdout.log 文件就有相应内容啦。

1
2
~> tail -f stdout.log
2018-11-18T10:52:57.333Z [INFO] This is an information.

不够刺激？

1
2
3
[...Array(10000)].forEach((item, index) => {
    Logger.info('Hello! ' + index);
});
1
2
3
4
5
6
7
8
9
10
11
12
~> tail -f stdout.log
...
2018-11-18T10:58:30.661Z [INFO] Hello! 9990
2018-11-18T10:58:30.661Z [INFO] Hello! 9991
2018-11-18T10:58:30.661Z [INFO] Hello! 9992
2018-11-18T10:58:30.661Z [INFO] Hello! 9993
2018-11-18T10:58:30.661Z [INFO] Hello! 9994
2018-11-18T10:58:30.661Z [INFO] Hello! 9995
2018-11-18T10:58:30.661Z [INFO] Hello! 9996
2018-11-18T10:58:30.661Z [INFO] Hello! 9997
2018-11-18T10:58:30.661Z [INFO] Hello! 9998
2018-11-18T10:58:30.661Z [INFO] Hello! 9999

搞定(┌・ω・)┌超简单的吧。

]]> <p>虽然 <code>console.log</code> 很好用，但是生产环境需要保存日志的时候就比较蛋疼。暴力 <code>fs.appendFile</code> 会消耗大量的 file handler，因此用 writable stream 来复用 file handler 是更好的选择。</p> 重构 StickerSetBot https://blog.phoenixlzx.com/2018/09/28/stickerset2packbot-refactory-with-telegraf/ 2018-09-28T02:51:03.000Z 2020-09-14T04:20:19.886Z 关注 Telegraf 有一段时间了。特别是最近 Telegram 上 spammer 猖獗导致 Telegram 对于用户行为限制越来越严格，由此想过写一个简单的 bot 来处理加群请求之类的。

总之原因都是没时间。终于搞定一些事情之后发现之前瞎写的 Telegram 导出贴图 bot 居然备受欢迎…正好 Telegram Bot API 也更新了，来重构吧！

拆分逻辑代码

最头疼的事情首先是当时写这 bot 的时候只顾着考虑各种情况，逻辑像流水一样全部写成一坨。虽然实际不复杂吧但这不是 best practice。于是把每个功能单独拆出来先。

on('command') 的逻辑代码整块移出来作为 handler，然后能够原子化的功能再单独拆分成函数调用。目前的效果虽然还是有不少逻辑层在 handler 里，但是基本达到了比较方便维护的目的。

handler 本来就是拿来写逻辑的啊摔

接下来再清理冗余代码和各种 hard code，加了两个方法让代码看起来更整洁一些。于是就先这样。

迁移框架

好在 Telegraf 和之前用的框架在参数上很多兼容，所以这没有花太多时间。顺便尝试采用了一部分 ES6 的风格，嘛…果然不喜欢。

所以就不要吐槽为什么 ES5 和 ES6 的风格混写了。

之前要一大长串的传参现在只要一个 context 了好方便啊。中间件也好方便啊~

以上。

调试：无尽的 bugfix

并不指望一通大换血之后的代码能一次跑起来…但是没跑起来的原因是我传错了中间件值这不能忍！！为什么一会儿传的是函数本体一会儿传的是函数调用啊摔！！

而且这问题还让我调了两个小时！！！

调通了之后就很舒服了

遇到的坑还有 context 本身不能当 session 用，然而不想再引入 session 中间件于是自己写了个超简陋的内存 session。就是为了多语言支持。因为一觉醒来发现这 bot 语言莫名其妙变中文了（messages 成了全局变量 = =

当然还有 Telegram 自己的坑，比如什么贴纸就是死下载不能然后整个程序就 hang 着了。

一键导出贴纸包

终于！Telegram bot API 添加了 StickerSet 类型。只要有贴纸包名称，就可以获取整个贴纸包的信息。考虑不改变用户习惯的情况下（你哪有什么用户啊可恶）对本身处理贴纸和其他消息的函数做了修改，顺便又拆了俩函数出来（怎么代码越来越多了啊喂！

最后结果就是没有一屏看不到头的函数啦~（你快够

以及加入了用贴纸包链接导出一整组贴纸的功能，算是真正意义上的 StickerSetBot 了。

然后贴纸过多卡死了 Telegram 的 ratelimiting

直接导出单张贴纸

既然功能拆分了那也就方便加更多别的功能啦。比如不新建任务，直接甩过去一张贴纸来获得 PNG 文件~

这只 bot 在这里，源码在这里。欢迎各种玩坏~（记得去发 issue

就酱(,,•﹏•,,)

]]> <p>关注 <a href="https://telegraf.js.org/">Telegraf</a> 有一段时间了。特别是最近 Telegram 上 spammer 猖獗导致 Telegram 对于用户行为限制越来越严格，由此想过写一个简单的 bot 来处理加群请求之类的。</p> <p>总之原因都是没时间。终于搞定一些事情之后发现之前瞎写的 <a href="https://blog.phoenixlzx.com/2016/08/23/my-first-yet-useless-telegram-bot/">Telegram 导出贴图 bot</a> 居然备受欢迎…正好 Telegram Bot API 也更新了，来重构吧！</p> Office Service Router 解决方案：Arch Linux in RAM https://blog.phoenixlzx.com/2018/08/04/archlinux-ramroot-office-service-router/ 2018-08-04T08:03:11.000Z 2020-09-14T04:20:19.886Z 一直把自己在办公室的 PC 保持开机用于连回办公区、存取数据工作需求。由于最近办公室所在的写字楼要全馆断电检点，所以诞生了构建一个 Service Router 的想法。

思路

运行在内存里对于 Linux 系统来说是完全可能（而且简单）的事情。

最直接的想法就是使用内核 hook 在启动时复制根分区到内存盘然后挂载内存里的数据作为根分区即可。

设备的话，设置 Power on AC 即可通电自启动。

ramroot

作为一只懒卷，这种简单的事情当然先顺手搜索下啦。然后就发现了几乎完美的解决方案——ramroot

ramroot 通过加入内核 hook 然后自动在内存建立 zram 分区，同步根分区数据再启动。还可以在启动时选择是否启动进内存，正好解决了所有的需求。

实现

硬件选择是一台便宜的 Intel NUC，安装两根 4GB LPDDR3 低压内存和一块 120G 2.5 SSD。虽然说起来其实并不需要 SSD（因为数据全部都在内存里，速度比 SSD 更快）但是毕竟日本多震，还是为数据安全着想。毕竟硬盘坏了的话内存系统也无法启动了。

当然如果有集成 32GB eMMC 的小型 PC 的话也是好的选择。

正常安装完 Arch Linux 系统，安装 openssh 和各种必要的服务程序，修改配置文件，然后安装 ramroot 并执行

1
# ramroot enable

此时先别急着重启，先把不需要的包、缓存等文件（/var/cache）删除，保持最小化的根分区。然后再重启。便可看到加载内核 hook 时的提示是否进入内存系统，默认超时后就会自动复制根分区到内存啦。

由于整个系统是运行在内存中的，所以完全没有等待读盘的时间。整个系统的响应速度非常快。限制是内存不够大的话运行一些业务会比较捉襟见肘，而且这样低功耗、低发热的 SoC 处理性能也只能运行一些轻型任务。

下面是一些 IO 性能测试

1
2
3
4
5
6
7
8
9
10
11
12
# ioping -s 1G /
1 GiB <<< . (ext4 /dev/zram0): request=1 time=1.04 s (warmup)
1 GiB <<< . (ext4 /dev/zram0): request=2 time=1.04 s
1 GiB <<< . (ext4 /dev/zram0): request=3 time=1.04 s
1 GiB <<< . (ext4 /dev/zram0): request=4 time=1.04 s
1 GiB <<< . (ext4 /dev/zram0): request=5 time=1.04 s
1 GiB <<< . (ext4 /dev/zram0): request=6 time=1.04 s ^C

--- / (ext4 /dev/zram0) ioping statistics ---
5 requests completed in 5.18 s, 5 GiB read, 0 iops, 988.4 MiB/s
generated 6 requests in 7.20 s, 6 GiB, 0 iops, 853.8 MiB/s
min/avg/max/mdev = 1.04 s / 1.04 s / 1.04 s / 550.7 us
1
2
3
4
5
6
# ioping -RD /

--- / (ext4 /dev/zram0) ioping statistics ---
530.0 k requests completed in 2.49 s, 2.02 GiB read, 212.9 k iops, 831.7 MiB/s
generated 530.0 k requests in 3.00 s, 2.02 GiB, 176.7 k iops, 690.1 MiB/s
min/avg/max/mdev = 3.44 us / 4.70 us / 69.0 us / 1.39 us

可以看到系统根分区在 zram 里，经过压缩因此 IO 带宽受到了 CPU 处理性能的限制。但是 IOPS 依然高得爆表，对比一下 Intel Optane 900P 的 IOPS 性能：

1
2
3
4
# ioping -RD /
--- / (ext4 /dev/nvme0n1p1) ioping statistics ---
163.1 k requests completed in 3.00 s, 56.5 k iops, 220.8 MiB/s
min/avg/max/mdev = 11 us / 17 us / 114 us / 4 us

炒鸡厉害对不对！

不过需要做永久性修改的话还是要下面的方法之一

  • 重新挂载磁盘（虽然并不麻烦）然后手动修改配置文件
  • 重新挂载磁盘然后 rsync zram 到磁盘（方便但是可能会多一些不必要的东西）
  • 重启进入磁盘系统然后运行修改（需要物理接触）

硬件设置

进入系统 BIOS 设置，开启 Power on AC 或设置 Power Failure 后的操作，选择为 Power On （默认一般是 Last State）。

关闭系统、拔出电源，或意外断电后，再接入电源即可自动开机引导系统。因为数据本身就只在内存中，除了运行中的临时更改会丢失，系统和硬盘本体都是安然无恙的。

再也不担心办公室断电检查啦。

大概就是这样。

]]> <p>一直把自己在办公室的 PC 保持开机用于连回办公区、存取数据工作需求。由于最近办公室所在的写字楼要全馆断电检点，所以诞生了构建一个 Service Router 的想法。</p> 通过 SSH 修正安装有 GPU 的 HPE Proliant 服务器 https://blog.phoenixlzx.com/2018/08/04/fix-hpe-proliant-ilo4-display-with-gpu-installed-using-ssh/ 2018-08-03T17:45:00.000Z 2020-09-14T04:20:19.886Z 由于越来越多的渲染、压制等需求，托供货商的关系搞来一台带有独立显卡的 HPE 服务器。经过几番折腾（包括特别奇怪的 LS26-C14 电源线）麻烦了帮忙托管的数据中心的大兄弟好几回，终于算是上架可以开机了。

登入 iLO，安装许可证，启动 iLO Remote Console，打开电源，一切都很顺利。但是 Console 里显示 Early Initialization… 完成后，突然画面一黑，完全没了动静。

以为 iLO 出了 bug，冷重启好几次都是一样的结果。百思不得其解。

再重启一次。仔细观察了一番发现虽然没了画面，但是 POST Code 还是不断变化的，而且 Virtual Media 指示灯不断在闪烁，说明系统仍在正常运行，只是没有视频输出而已。

因此问题定位在视频输出而非系统硬件。既然这台服务器装了显卡，那么很可能是 PCI-e 初始化后视频输出全部交给显卡处理了。搜索了一下 HPE Community，确实有这样的情况存在。解决方案是通过 BIOS 修改显卡设置为默认集成显卡、备选独立显卡。

尝试在设备初始化阶段进入 BIOS，失败。

联系数据中心远程操作的话，可能要等一段时间。

纠结时随便点开 iLO 的管理页面，突然发现了华点：这货居然支持 SSH。

对啦，HPE 的底层系统几乎都是魔改版 Linux，连他们的 SmartArray 都是 Linux 启动一个 Firefox 浏览器来操作的（X

于是正好在网上搜到一篇通过 SSH 修改 BIOS 视频设置的方法。记录如下。

SSH 进入 iLO

确保 SSH 在 iLO 管理页面中已开启，然后使用 SSH 客户端正常连接：

1
ssh Administrator@10.6.254.121

（ssh 用户名是 Administrator 感觉各种违和）

连接到 Virtual Serial Port

命令很简单：vsp

在 iLO 管理页面重启系统，然后等待初始化完成。如果看到按下 F9 进入 BIOS 设置的提示，不要按下它否则会进入 GUI 模式（于是又去独立显卡了就。

看到 ESC + 9 进入 BIOS Setup Utility 时按下键组合，稍等一会儿应该就可以看到提示符 rbsu>。

修改视频设置

命令 SHOW CONFIG VIDEO OPTIONS

显示如下

1
2
3
1|Optional Video Primary, Embedded Video Disabled <=
2|Optional Video Primary, Embedded Video Secondary
3|Embedded Video Primary, Optional Video Secondary

即默认关闭了集成显卡，只用独立显卡（不觉得很蠢吗！

于是修改为第三项，默认使用集成显卡，独立显卡作为备用。

1
SET CONFIG VIDEO OPTIONS 3
1
2
3
1|Optional Video Primary, Embedded Video Disabled
2|Optional Video Primary, Embedded Video Secondary
3|Embedded Video Primary, Optional Video Secondary <=

然后敲 EXIT 退出并重启系统。

安装系统和驱动

至此即可通过 iLO Advanced Console 正常安装操作系统。不过需要注意的是进入操作系统后即便安装了对应的显卡驱动，依然默认使用的是集成显卡。以及 RDP 只能使用软解，无法使用独立显卡加速视频输出。这不影响 Blender 或者 Cinema 4D 等直接操作显卡进行计算的程序，但是会影响直接输出视频到桌面的程序。通过 Teamviewer 则可以强制桌面运行在独立显卡上。

顺便吐槽：Blender 把我的工程材质弄丢了…

]]> <p>由于越来越多的渲染、压制等需求，托供货商的关系搞来一台带有独立显卡的 HPE 服务器。经过几番折腾（包括特别奇怪的 LS26-C14 电源线）麻烦了帮忙托管的数据中心的大兄弟好几回，终于算是上架可以开机了。</p> <p>登入 iLO，安装许可证，启动 iLO Remote Console，打开电源，一切都很顺利。但是 Console 里显示 Early Initialization… 完成后，突然画面一黑，完全没了动静。</p> 在线扩展 LVM root 分区 https://blog.phoenixlzx.com/2018/06/06/resize-lvm-rootfs-online/ 2018-06-06T14:31:03.000Z 2020-09-14T04:20:19.882Z 才不是没东西写了呢

遇到一个奇葩的原因导致 root 分区被占满的。而且还是奇葩的 CentOS，root 分区是 LVM，Hypervisor 里扩展磁盘后无法直接用 resize2fs。

既然如此就只能暴力重建分区咯。

重建分区

操作前确保操作的分区和之后新建时 Start 保持一致，修改分区表后不至于分区崩坏。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
~> fidks /dev/sda
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p

Disk /dev/sda: 103.1 GB, 103079215104 bytes, 201326592 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000a8e23

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     2099199     1048576   83  Linux
/dev/sda2         2099200    50331647    24116224   8e  Linux LVM

Command (m for help): d
Partition number (1,2, default 2): 2
Partition 2 is deleted

Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p):
Using default response p
Partition number (2-4, default 2):
First sector (2099200-201326591, default 2099200):
Using default value 2099200
Last sector, +sectors or +size{K,M,G} (2099200-201326591, default 201326591):
Using default value 201326591
Partition 2 of type Linux and of size 95 GiB is set

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

~> partprobe

现在就可以看到 /dev/sda2 的大小已经变化了：

1
2
3
4
5
6
7
8
~> lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda               8:0    0   96G  0 disk
├─sda1            8:1    0    1G  0 part /boot
└─sda2            8:2    0   95G  0 part
  ├─centos-root 253:0    0 20.6G  0 lvm  /
  └─centos-swap 253:1    0  2.4G  0 lvm  [SWAP]
sr0              11:0    1  906M  0 rom

扩展 Volume Group

VG 的好处也就是能够灵活扩展分区大小…

1
2
3
~> pvresize /dev/sda2
  Physical volume "/dev/sda2" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
~> vgdisplay
  --- Volume group ---
  VG Name               centos
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <95.00 GiB
  PE Size               4.00 MiB
  Total PE              24319
  Alloc PE / Size       5887 / <23.00 GiB
  Free  PE / Size       18432 / 72.00 GiB
  VG UUID               TpbtuH-AjTZ-PU3v-UN31-FvfX-kSLv-xLiJG7

至此已经可以看到 Free PE 的部分有多出的 72GB 空间。

扩展 Logic Volume

1
2
3
4
5
6
7
8
9
10
11
12
13
~> lvextend -r -l +100%FREE /dev/centos/root
  Size of logical volume centos/root changed from 20.59 GiB (5272 extents) to 92.59 GiB (23704 extents).
  Logical volume centos/root successfully resized.
meta-data=/dev/mapper/centos-root isize=512    agcount=4, agsize=1349632 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=5398528, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2636, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 5398528 to 24272896

确认效果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
~> lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda               8:0    0   96G  0 disk 
├─sda1            8:1    0    1G  0 part /boot
└─sda2            8:2    0   95G  0 part 
  ├─centos-root 253:0    0 92.6G  0 lvm  /
  └─centos-swap 253:1    0  2.4G  0 lvm  [SWAP]
sr0              11:0    1  906M  0 rom

~> df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   93G   21G   73G  23% /
devtmpfs                 3.9G     0  3.9G   0% /dev
tmpfs                    3.9G  8.0K  3.9G   1% /dev/shm
tmpfs                    3.9G  8.6M  3.9G   1% /run
tmpfs                    3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sda1               1014M  185M  830M  19% /boot
tmpfs                    783M     0  783M   0% /run/user/0

搞定收工(‘・ω・’)

后话

其实虚拟机还用 LVM 的话，直接新增一块虚拟硬盘是最方便的方案。直接 vgextend 一路搞定…

]]> <p><del><em>才不是没东西写了呢</em></del></p> <p>遇到一个奇葩的原因导致 root 分区被占满的。而且还是奇葩的 CentOS，root 分区是 LVM，Hypervisor 里扩展磁盘后无法直接用 resize2fs。</p> 在 Linux 服务器配置 LACP 与 VLAN https://blog.phoenixlzx.com/2018/04/18/play-with-linux-lacp-bonding-on-vlan/ 2018-04-18T05:59:11.000Z 2020-09-14T04:20:19.879Z 存储服务器不想放在 OVH 了。所以自己来托管一台机器，顺便折腾下 2x1Gbps 组 LACP Bonding。

前提：服务器需要至少 2 个千兆物理网卡，上联交换机支持 802.3ad。

配置交换机

这里使用的是 Cisco Nexus 3064PQ-10GE 交换机，我们的接口在 Eth1/21-22，port-channel 的配置如下：

1
2
3
4
5
6
7
8
9
# show interface trunk

--------------------------------------------------------------------------------
Port          Native  Status        Port
              Vlan                  Channel
--------------------------------------------------------------------------------
Eth1/21       1       trnk-bndl     Po100
Eth1/22       1       trnk-bndl     Po100
Po100         1       trunking      --
1
2
3
4
5
6
7
8
9
10
show port-channel database
port-channel100
    Last membership update is successful
    2 ports in total, 2 ports up
    First operational port is Ethernet1/21
    Age of the port-channel is 0d:00h:02m:16s
    Time since last bundle is 0d:00h:02m:04s
    Last bundled member is Ethernet1/22
    Ports:   Ethernet1/21    [active ] [up] *
             Ethernet1/22    [active ] [up]

配置服务器

服务器操作系统是 Arch Linux，由于蜜汁问题 netctl 无法启动网卡，就只好用 systemd-networkd 啦。

麻烦一些，但是也还算顺利。与往常一样，折腾服务器网络的时候需要备着 IPMI 以防 connection lost。

内核模块

需要加载 bonding 模块。将模块名写入列表，文件 /etc/modules-load.d/bonding.conf，内容只需要一行：

1
bonding

先别急着加载模块，为了防止模块自动建立一个默认网卡影响后续配置，以及设置 LACP Mode=4 … 等等，先加入一行参数。文件 /etc/modprobe.d/bonding.conf

1
options bonding mode=4 miimon=100 max_bonds=0

然后安装 ifenslave 包，再 modprobe bonding 即可。

bonding 虚拟网卡

首先创建一个虚拟网卡的设备。文件 /etc/systemd/network/bond0.netdev 内容为

1
2
3
4
5
6
7
8
9
[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=802.3ad
TransmitHashPolicy=layer2+3
LACPTransmitRate=fast
AdSelect=bandwidth

然后在此虚拟网卡上创建网络。这里使用两个物理网卡 eth0 和 eth1 作为 bundle，交换机上的 VLAN id 是 113。文件 /etc/systemd/network/bond0.network 内容为

1
2
3
4
5
6
[Match]
Name=bond0

[Network]
VLAN=vlan113
BindCarrier=eth0 eth1

接下来分别为 eth0 和 eth1 建立网络设置。

  • /etc/systemd/network/eth0.network
1
2
3
4
5
[Match]
Name=eth0

[Network]
Bond=bond0
  • /etc/systemd/network/eth1.network
1
2
3
4
5
[Match]
Name=eth1

[Network]
Bond=bond0

最后是 VLAN 的设置。前面设置了上联 VLAN id 是 113，这里分别建立 VLAN 的虚拟网卡(based on bond0) 并设置网络(IP, etc)。

  • /etc/systemd/network/vlan113.netdev
1
2
3
4
5
6
[NetDev]
Name=vlan113
Kind=vlan

[VLAN]
Id=113
  • /etc/systemd/network/vlan113.network
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[Match]
Name=vlan113

[Network]
VLAN=vlan113

[Address]
Address=10.1.0.100/24

[Route]
Destination=0.0.0.0/0
Gateway=10.1.0.1
DNS=1.1.1.1

[Address]
Address=2600:x:x:x::2/64

[Route]
Gateway=2600:x:x:x::1

多个地址、IPv6 等可以写多个 [Address] 和 [Route]。

至此就完成啦。开启 systemd-networkd 的自启动：

1
systemctl enable systemd-networkd.service

然后重启网络：

1
systemctl restart systemd-networkd.service

如果配置都没有问题，网络会中断十几秒然后恢复。现在查看网卡列表已经可以看到组合的网卡了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether <REDACTED> brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether <REDACTED> brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether <REDACTED> brd ff:ff:ff:ff:ff:ff
5: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether <REDACTED> brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether <REDACTED> brd ff:ff:ff:ff:ff:ff
7: vlan113@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether <REDACTED> brd ff:ff:ff:ff:ff:ff

ethtool 查看 bond0 的速率显示 2000Mb/s：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# ethtool bond0
Settings for bond0:
        Supported ports: [ ]
        Supported link modes:   Not reported
        Supported pause frame use: No
        Supports auto-negotiation: No
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: 2000Mb/s
        Duplex: Full
        Port: Other
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Link detected: yes

搞定收工(‘・ω・’)

Reference:

]]> <p>存储服务器不想放在 OVH 了。所以自己来托管一台机器，顺便折腾下 2x1Gbps 组 LACP Bonding。</p> 迁移 DokuWiki 到 BookStackApp https://blog.phoenixlzx.com/2018/03/23/migrate-dokuwiki-to-bookstack/ 2018-03-22T15:12:08.000Z 2020-09-14T04:20:19.876Z Wiki 这么反人类的语法是怎么存在这么久的？？？？？？？

总之受不了 Wiki 语法的可维护性了。什么？这玩意儿有维护性？？？

以及万年不更新的各种插件。系统升级后 PHP 7 不兼容，一看还是 swiftmail 的问题。生气。

正好有需求要整合一套知识库平台，搜索了一下 Confluence 的 alternative，发现了 BookStackApp 和 Phabricator。

前者适合个人或开源社区使用，后者则是一整套企业协作解决方案。对于我的需求来讲，BookStackApp 就足够啦。

页面数据

DokuWiki 并不使用数据库，因此没有一个通用的中间件来实现数据格式转换。而 DokuWiki 的语法非常奇葩——比如，它的一级标题是 ====== 这样 ======，六级标题才是 = 这样 =，正好和一般的 Wikitext 倒置。图片、内链等的表达方式也相当愚蠢，这些问题使我在思考迁移方案的第一个小时内就放弃了直接从源码转移的途径。

顺便，还有另外一个问题——本来为了使 Wiki 易于编写，这 DokuWiki 还安装了 Markdown 插件。因此部分页面中混杂着 Markdown 语法，更增加了源码处理的复杂度。

综合来看，最通用的数据格式，就是最终渲染出来的 XHTML 了。

图片

DokuWiki 的图片存储策略也是非常的奇特。由于它没有数据库，因此为了保持图片与页面的对应，它将图片存储在每个页面同样的路径下，并通过执行 PHP 的方式获取（扶额。

更甚者！！！

外链的图片，也是通过 /lib/exe/fetch.php 带参数来获取！！

我 的 天 哪。

因此既然在页面数据的考量中决定了使用最终渲染输出的 XHTML 来处理数据格式，图片也需要特殊的下载和归档技巧。这将需要使用 sanitize-html 提供的 transformer 方法来实现。

逻辑实现

一开始尝试了一些 Site Exporter 插件，但遗憾的是并没有什么真正能派上用场。甚至一些暴力递归下载所有页面和资源的脚本的表现也非常糟糕。

但是根据 DokuWiki 的官方 Tips，它可以将文章内容单纯导出 XHTML，只需要加上 ?do=export_xhtmlbody 参数即可。这就方便了，因为这样只需要一个完整的页面列表就可以了。随便找一个可以输出子命名空间的插件，新建一个页面用于从根命名空间展开就 OK 啦。

请求这个列表页面的 XHTML body 输出，使用 cheerio 遍历所有的 a 标签，就获得了所有要导出的页面地址。分别再去请求这些页面的 XHTML body 输出，做如下处理：

  1. 跟踪所有的 img 标签，下载图片文件并按预定义的路径规则和文件名归档。
  2. sanitize-html 清除所有不必要的标签、样式、id 和 class。
  3. sanitize-html 按预定义的路径规则更新所有 a 和 img 标签属性。

看代码

后来发现 DokuWiki 的性能不足以支撑异步请求的速度，额外加上了 sleep 模块来控制请求频率（扶额。

脚本执行完后，将图片目录移动到 BookStackApp 的对应位置，便可以直接读取所有的 HTML 文件来导入数据啦。

用了这么久，才发现原来还有比 raw HTML 更难以维护的数据格式啊…（望天。

]]> <p>Wiki 这么反人类的语法是怎么存在这么久的？？？？？？？</p> 制作 Arch Linux 系统模板镜像 https://blog.phoenixlzx.com/2018/02/01/build-archlinux-image-template-for-aliyun/ 2018-02-01T05:09:02.000Z 2020-09-14T04:20:19.882Z 阿里云镜像制作踩坑记。

此文章主要记录按照阿里云 Customized Linux 制作 VPC 镜像的过程。一些部分也可用作制作其他平台镜像的参考。

当然记录的原因主要是 Arch 上的 cloud-init 打死无法在阿里云上修改 root 密码，就很气。

建立虚拟机

因为要制作 Customized Linux，所以第一步无法在阿里云平台上使用公共镜像制作。本机启动一个 Virtual Box，新建虚拟机，虚拟磁盘选择 RAW/IMG 格式即可。

按照一般步骤安装 Arch Linux，需要整个磁盘仅有一个分区。虽然很多平台支持多分区的镜像文件，但是莫名在这里踩了坑所以。

（另外吐槽：vps2arch 居然不帮我把 base-devel 装全了？！）

系统配置

安装一些必需的包。

1
# pacman -S qemu-guest-ga openssh

启用服务。

1
2
3
# systemctl enable qemu-ga
# systemctl enable sshd
# systemctl enable systemd-networkd

网络配置

哪个魂淡跟我讲 VPC 是 DHCP？装着 cloud-init 的 Arch 就可以自动设置内网 IP，这个没装的就 GG。

修改文件 /etc/systemd/network/default.network

1
2
3
4
5
[Match]
Name=en*

[Network]
DHCP=ipv4

总之先这样放着。

定制脚本

根据阿里云的文档，cloud init 不生效的时候需要用约定好的配置文件和脚本完成各种兼容动作。

新建目录 /aliyun_custom_image

新建文件 /usr/bin/aliyun-custom-os，写入内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
#!/bin/bash

os_conf_dir=/aliyun_custom_image
os_conf_file=${os_conf_dir}/os.conf

load_os_conf() {
    if [[ -f $os_conf_file ]]; then
        . $os_conf_file
        echo $password
        return 0
    else
        return 1
    fi
}

cleanup() {
    # ensure $os_conf_file is deleted, to avoid repeating config system
    rm $os_conf_file >& /dev/null
    # ensure $os_conf_dir is exitst
    mkdir -p $os_conf_dir
}

config_password() {
    if [[ -n $password ]]; then
        password=$(echo $password | base64 -d)
        if [[ $? == 0 && -n $password ]]; then
            echo "root:$password"
            echo "root:$password" | chpasswd
        fi
    fi
}
config_hostname() {
    if [[ -n $hostname ]]; then
        echo "$hostname" > /etc/hostname
        hostnamectl set-hostname $hostname
    fi
}
config_network() {
    if [[ -n $eth0_ip_addr ]]; then
        config_interface
        systemctl restart systemd-networkd
    fi
}
config_interface() {
    mask2cdr $eth0_netmask
    cat << EOF > /etc/systemd/network/default.network
# Generated by Aliyun Custom OS helper
# DO NOT EDIT THIS FILE! IT WILL BE OVERWRITTEN

[Match]
Name=$(ip link | awk -F: '$0 !~ "lo|vir|wl|^[^0-9]"{print $2a;getline}' | sed -e 's/^[[:space:]]*//')

[Network]
Address=$eth0_ip_addr/$netmask
Gateway=$eth0_gateway

[Link]
MACAddress=$eth0_mac_address

[Address]
Address=$eth0_ip_addr/$netmask
EOF
    echo "nameserver 1.1.1.1" > /etc/resolv.conf
    for ns in $dns_nameserver
    do
        echo "nameserver $ns" >> /etc/resolv.conf
    done
}

mask2cdr() {
    # Assumes there's no "255." after a non-255 byte in the mask
    local x=${1##*255.}
    set -- 0^^^128^192^224^240^248^252^254^ $(( (${#1} - ${#x})*2 )) ${x%%.*}
    x=${1%%$3*}
    netmask=$(( $2 + (${#x}/4) ))
}

if load_os_conf ; then
    config_password
    config_hostname
    config_network
    cleanup
else
    echo "not load $os_conf_file"
fi

赋予执行权限

1
# chmod +x /usr/bin/aliyun-custom-os

新建 systemd unit 文件 /usr/lib/systemd/system/aliyun-custom-os.service 写入内容

1
2
3
4
5
6
7
8
9
10
11
12
[Unit]
Description=Aliyun Custom OS Helper Script

[Service]
Type=oneshot
ExecStart=/usr/bin/aliyun-custom-os
TimeoutSec=30
StandardInput=tty
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

然后启用这个服务

1
systemctl enable aliyun-custom-os

挂载镜像

正常 shutdown 虚拟机，然后拿到镜像文件的路径。例如 ~/vm/archlinux.img。

接下来需要将此镜像挂载到宿主机系统中修改、清理文件。首先确定镜像文件中的分区位置：

1
2
$ file ~/vm/archlinux.img
archlinux.img: x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 41938944 sectors, code offset 0x63

得知 startsector 为 2048

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ fdisk -l ~/vm/archlinux.img
You must set cylinders.
You can do this from the extra functions menu.

Disk archlinux.img: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x91d8e293

        Device Boot      Start         End      Blocks   Id  System
archlinux.img1   *           1        2611    20969472   83  Linux
Partition 1 has different physical/logical endings:
     phys=(1023, 254, 63) logical=(2610, 180, 2)

得知 sectorsize 为 512。

使用 mount 命令带 offset 参数挂载镜像中的分区：

1
2
$ sudo mkdir -p /mnt/img
$ sudo mount -t ext4 -o loop,offset=$((2048*512)) /path/to/archlinux.img /mnt/img/ # 更改 -t auto 或者其他此分区使用的文件系统格式

就可以 cd /mnt/img 看到镜像里的 rootfs 啦。

清理/检查文件

要删除的：

1
2
3
4
5
# rm /root/.bash_history # _(:з」∠)_
# rm /etc/ssh/ssh_host_* # 强制每次部署的时候重新生成密钥对
# rm -r /var/log/* # 清理不需要的日志
# rm -r /var/cache/* # 清理缓存
# rm /etc/resolv.conf.bak # 避免恢复成制作时的 DNS

要检查的：

/etc/hosts - 我不知道为什么，第一次的时候把这个文件留空了(:з」∠)

/etc/resolv.conf - 鉴于总是有人喜欢手动修改这个文件，所以直接把它写成静态文件好了。内容例如

1
2
nameserver 8.8.8.8
nameserver 8.8.4.4

/etc/ssh/sshd_config 中是否允许 root 密码登陆。

准备镜像

退出 /mnt/img 目录，然后卸载镜像

1
# umount /mnt/img

（可选）使用 qemu-img 转换镜像格式到 VHD，减少镜像文件大小。特别是对国内的小水管上传（心疼

1
$ qemu-img convert -f raw -O vpc archlinux.img archlinux.vhd

上传镜像

在相同的 region 创建一个 OSS bucket，然后创建一个 RAM 子用户赋予 OSS 写权限并创建 Access Key，使用 OSSBrowser 上传准备好的 VHD 文件。

上传完毕后，在 ECS 标签下的镜像标签即可导入镜像。如果是第一次操作，需要给 ECS 授权访问 OSS。在导入的页面提示中提供了授权的链接。镜像内容配置如下：

  • OSS Object 地址：镜像文件在 OSS 中的 URL
  • Image 名称：archlinux-2018.1-x86_64 … 等符合要求即可
  • 操作系统：Linux
  • 系统盘大小：40GB
  • 系统架构：x86_64
  • 系统平台：Customized Linux
  • 镜像格式：VHD（如果是 img 就选 RAW）
  • 镜像描述：随便写啦。

确定后应该就会开始制作镜像了。

测试

因为没有做经典实例的兼容，这个镜像只能用于 VPC 的实例。总体而言，cloud-init 本来兼容的 Arch 却无法更改 root 密码（其他的倒是没问题），所以才选择了用一个 dirty 的方案来实现。

不知道应该说阿里云的工程师对自定义镜像的考虑周到还是对不同发行版的考虑欠妥…？

最后庆幸倒腾来去上传了好多遍 20G 的文件，日本运营商家宽带宽对等真的是帮了大忙，不然一个镜像制作不知道要到什么时候 > > （斜眼看国内三大运营商

参考：

]]> <p>阿里云镜像制作踩坑记。</p> <p>此文章主要记录按照<a href="https://www.alibabacloud.com/help/zh/faq-detail/51138.htm">阿里云 Customized Linux</a> 制作 VPC 镜像的过程。一些部分也可用作制作其他平台镜像的参考。 </p> <p>当然记录的原因主要是 Arch 上的 cloud-init 打死无法在阿里云上修改 root 密码，就很气。</p>