渔人小径 · 唯逻辑不破
一言以蔽之，同用双核，略逊Pi 4B，明显不如RK3399。虽然制程和频率双双强过BCM2711（Pi 4B），但A55相比A72应该还是有明显差距的…吧，当然发行版对比也略有差异（尽管都基于debian），无法精确对比哈。
至于想劝俺上什么iStoreOS就算了，原因在之前提过，尽管估计物理跑NAT（开启软件流量分载）大概率能接近跑满千兆转发，但选型喜好是很个人的事情，总觉得所谓all-in-one在架构上反过来（upside down）不好玩。
数据上，iperf3上行700左右，下行850，看起来即使另外两核跑个容器带点儿负载，保障个500Mbps宽带应该没啥鸭梨。
During maintenance of a production server, we use to encounter a problem like this – an internet-access-blocked port, say 3306 (mysql), is about to be open for a little while due to debugging needs, which is not uncommon, right? So how to make this easily operated, mostly secure, and automatically disabled after working – I guess this’s gonna help somehow.
A Linux server with whatever the distribution including iptables (e.g. CentOS, Rocky for now as example), Nginx, fcgiwrap, a simple shell script and a commonly used web browser, let’s say chrome, will be major ingredients on the recipe.
常做运维，总会遇到某些线上服务器，为了便于调试，在符合安全要求的基础上，需要相对便利的对公网短时定向开放某些端口。
昨天想了一招，用nginx操作shell脚本，对特定公网IP开口子，叫一声“芝麻开门”，便捷又安全。举例端口3306（mysql），系统是Rocky Linux 8（原CentOS 8）。
Doors of Durin
先查一下现有的防火墙规则，需要的话可以保存一下。换句话说，搞芝麻开门之前，先确定门是隐藏的；也即已经有相应（且持久化）的iptables rule确保到被保护端口的连接是DROP/REJECT状态。
|
1 2 3 4 5 6 7 8 9 10 11 |
[root@localhost ~]# iptables -nvL Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 48772 9041K ACCEPT tcp -- * * 10.0.0.0/8 0.0.0.0/0 tcp 6 376 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination |
然后就是fcgiwrap的安装，此处就不写nginx安装过程了，默认安装即可。
安装后增加两个systemd服务文件，并测试fcgiwrap服务生效。
【注】那俩服务文件，在Redhat之外的发行版上，fcgiwrap安装包可能自带，请针对所用版本自行检查。
|
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 |
[root@localhost ~]# dnf install fcgiwrap 上次元数据过期检查：2:45:15 前，执行于 2022年02月09日 星期三 20时00分42秒。 依赖关系解决。 （……部分省略） 已安装: fcgi-2.4.0-36.el8.x86_64 fcgiwrap-1.1.0-12.20181108git99c942c.el8.x86_64 完毕！ [root@localhost ~]# [root@localhost ~]# cat /usr/lib/systemd/system/fcgiwrap.service [Unit] Description=Simple CGI Server After=nss-user-lookup.target Requires=fcgiwrap.socket [Service] EnvironmentFile=/etc/sysconfig/fcgiwrap ExecStart=/usr/sbin/fcgiwrap ${DAEMON_OPTS} -c ${DAEMON_PROCS} User=nginx Group=nginx [Install] Also=fcgiwrap.socket [root@localhost ~]# cat /usr/lib/systemd/system/fcgiwrap.socket [Unit] Description=fcgiwrap Socket [Socket] ListenStream=/run/fcgiwrap.socket [Install] WantedBy=sockets.target [root@localhost ~]# systemctl daemon-reload [root@localhost ~]# systemctl enable fcgiwrap.service —now Created symlink /etc/systemd/system/sockets.target.wants/fcgiwrap.socket → /usr/lib/systemd/system/fcgiwrap.socket. [root@localhost ~]# systemctl status fcgiwrap.service ● fcgiwrap.service - Simple CGI Server Loaded: loaded (/usr/lib/systemd/system/fcgiwrap.service; indirect; vendor preset: disable> Active: active (running) since Wed 2022-02-09 22:54:17 CST; 4s ago Main PID: 814486 (fcgiwrap) Tasks: 1 (limit: 23712) Memory: 492.0K CGroup: /system.slice/fcgiwrap.service └─814486 /usr/sbin/fcgiwrap -f -c 1 2月 09 22:54:17 localhost.localdomain systemd[1]: Started Simple CGI Server. [root@localhost ~]# |
接下来为一个新的nginx server准备个根目录，存放网页和之后控制iptables的脚本。
完整阅读本篇»So here’s a quick example. OpenWrt shows capability to provide business-level internet access reliabilities – with not only load balancing/failover between 2 or more ISPs, but also VRRP based hardware (dual x86 vm in this experiment) level redundancy.
从以下的例子可以看出，OpenWrt基本满足了提供小型商业级Internet访问可靠性的初步要求。它不仅可以在多个ISP之间实现负载均衡以及故障切换，在此基础上同时提供基于VRRP的硬件冗余（本实验中为双x86虚拟机）。
先开仨虚拟机，前两台做OpenWrt，可以先做1台，复制1台。注意要安装mwan3和keepalived。
双WAN做好后，断开一路wan做测试。这里的wanb，用的是楼道里的不可靠wifi，通过Raspberry Pi向下路由一层转成有线网，能体现出不稳定的ISP接入状态。
本来是两路负载均衡的策略，wanb断开后，5s之内可以让所有对外请求都稳定落在wan上。
下一步，把MASTER的br-lan断开，模拟一个路由器硬件直接宕掉。
这个切换时间很短，还没反应过来，BACKUP就接管了VIP地址，对外请求几乎不受什么影响。
Here I’m gonna show you a quick how-to on obtaining a wildcard SSL cert from Let’s Encrypt with the “pure shell written” acme.sh, which is simple, light-weight and far beyond flexible.
And you may already aware that I’ve an earlier post on doing this with another tool called certbot-auto, well, unfortuantely it’s… kinda still working… but having no support or further update anymore. As for the “official successor” of the certbot-auto? It seems the official guys have decided to walk step and step closer into the mire, with that good-looking but evil-inside snapd… oh, don’t even say that word again. It’s weird enough – I saw nothing around Canonical brand on sponsors list from homepage of Let’s Encrypt. That’s another topic anyway, a wildcard SSL cert for free is still worth my sincere appreciation in this case.
今天简单聊下如何使用acme.sh来获取通配符证书，纯shell工具比之前聊过的certbot-auto更为简单、轻量且灵活。此外不幸的是，半年不见certbot已然走上邪路，奇怪的是Let’s Encrypt首页赞助商清单里并未发现Canonical在列，让我倍感意外。
废话少叙，先装为敬。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
[root@aqui-test ~]# curl https://get.acme.sh | sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 937 0 937 0 0 445 0 --:--:-- 0:00:02 --:--:-- 445 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 204k 100 204k 0 0 33335 0 0:00:06 0:00:06 --:--:-- 28373 [Sat Feb 27 23:14:42 CST 2021] Installing from online archive. [Sat Feb 27 23:14:42 CST 2021] Downloading https://github.com/acmesh-official/acme.sh/archive/master.tar.gz [Sat Feb 27 23:15:47 CST 2021] Extracting master.tar.gz [Sat Feb 27 23:15:47 CST 2021] It is recommended to install socat first. [Sat Feb 27 23:15:47 CST 2021] We use socat for standalone server if you use standalone mode. [Sat Feb 27 23:15:47 CST 2021] If you don't use standalone mode, just ignore this warning. [Sat Feb 27 23:15:47 CST 2021] Installing to /root/.acme.sh [Sat Feb 27 23:15:47 CST 2021] Installed to /root/.acme.sh/acme.sh [Sat Feb 27 23:15:47 CST 2021] Installing alias to '/root/.bashrc' [Sat Feb 27 23:15:47 CST 2021] OK, Close and reopen your terminal to start using acme.sh [Sat Feb 27 23:15:47 CST 2021] Installing alias to '/root/.cshrc' [Sat Feb 27 23:15:47 CST 2021] Installing alias to '/root/.tcshrc' [Sat Feb 27 23:15:47 CST 2021] Installing cron job [Sat Feb 27 23:15:48 CST 2021] Good, bash is found, so change the shebang to use bash as preferred. [Sat Feb 27 23:15:49 CST 2021] OK [Sat Feb 27 23:15:49 CST 2021] Install success! [root@aqui-test ~]# |
安装过程中会自动创建cronjob，如果不想自动创建，安装时要加个参数，也可以手动把cronjob删掉（则证书不会自动展期）。
|
1 2 3 4 |
[root@aqui-test ~]# crontab -l # m h dom mon dow command 47 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null [root@aqui-test ~]# |
此时把阿里云key和secret填入环境变量（建议使用RAM账户，风险最小化）。
|
1 2 |
[root@aqui-test ~]# export Ali_Key="L123456789q" [root@aqui-test ~]# export Ali_Secret="j123456789l" |
然后一句话申请wildcard（通配符）证书。
完整阅读本篇»This post shows you how to use PBS (Proxmox Backup Server) to backup a specific directory (or mount point) of a PVE (Proxmox Virtual Environment) server, which is NOT exactly same thing in my mind – to backup a physical PVE machine and restore to be another new one (with all my personal settings in) though, but still somehow interesting and worth a try.
本文简介如何使用PBS（Proxmox Backup Server）进行PVE物理机备份。
本以为，这功能可以把pve物理机clone一份然后秒恢复成一台新物理机（类似硬盘dd但更简单）。但实际并非如此，该功能是把特定路径（比如根目录）下的文件整体打包备份（不含已挂载别的分区的路径）；而恢复时也不是整分区恢复，而是按文件恢复，且文件已经存在时会报错。
虽然跟想的不太一样，至少这货有一点好处，简便易操作。相当于给PVE物理机磁盘打了个snapshot，而且PBS的管理界面可以把备份解开，只下载（恢复）其中某一个文件，有一定的实用价值。
现在看下备份过程，在PVE物理机上执行如下命令 –
|
1 2 3 4 5 6 7 8 9 10 11 12 |
root@pve-test-pbs:~# proxmox-backup-client backup 121-root.pxar:/ --repository 192.168.1.122:test-store-01 Starting backup: host/pve-test-pbs/2020-10-13T03:06:41Z Client name: pve-test-pbs Starting backup protocol: Tue Oct 13 11:06:41 2020 Upload directory '/' to '192.168.1.122:test-store-01' as 121-root.pxar.didx 121-root.pxar: had to upload 1.67 GiB of 1.87 GiB in 23.20s, average speed 73.54 MiB/s). 121-root.pxar: backup was done incrementally, reused 208.00 MiB (10.9%) Uploaded backup catalog (1.00 MiB) Duration: 23.28s End Time: Tue Oct 13 11:07:04 2020 root@pve-test-pbs:~# |
其中 –
备份完成后，从PBS管理界面，可以看到备份信息。
更有意思的是，备份可以展开，甚至可以下载某一具体文件。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# root @ pbs-test in /mnt/datastore/test-store-01 [11:29:24] $ ll total 24K drwxr-xr-x 4 backup backup 4.0K Oct 13 11:06 host drwx------ 2 root root 16K Oct 12 15:29 lost+found drwxr-xr-x 3 backup backup 4.0K Oct 12 16:02 vm # root @ pbs-test in /mnt/datastore/test-store-01 [11:29:36] $ ll host/pve-test-pbs/2020-10-13T03:06:41Z total 40K -rw-r--r-- 1 backup backup 25K Oct 13 11:07 121-root.pxar.didx -rw-r--r-- 1 backup backup 4.2K Oct 13 11:07 catalog.pcat1.didx -rw-r--r-- 1 backup backup 399 Oct 13 11:07 index.json.blob |
那么如果从PVE上列出PBS的备份，从而检查内容和恢复呢？
完整阅读本篇»To get rid of snapd on Raspbian/RaspberryPi OS Buster, since it eats lots of cpu power, especially on the old hardware, like a Pi 2B.
一台年迈的Pi 2B，运行着时时更新的Raspbian Buster，兢兢业业给娃做文件服务器，不亦乐乎。
一天apt dist-upgrade之后，就发现system load频繁升高，系统空载就能吃掉大致一个核的性能。top后画风大致是这样的。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
➜ ~ top top - 22:26:04 up 2 days, 13:44, 3 users, load average: 0.96, 0.99, 0.93 Tasks: 143 total, 1 running, 142 sleeping, 0 stopped, 0 zombie %Cpu(s): 8.4 us, 2.7 sy, 0.0 ni, 82.4 id, 6.3 wa, 0.0 hi, 0.2 si, 0.0 st MiB Mem : 926.1 total, 222.2 free, 171.1 used, 532.7 buff/cache MiB Swap: 100.0 total, 100.0 free, 0.0 used. 693.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 345 root 20 0 968804 21248 13064 S 37.3 2.2 1065:41 snapd 84 root 20 0 0 0 0 S 1.0 0.0 28:27.25 jbd2/mmcblk0p2- 15049 pi 20 0 10440 3096 2540 R 1.0 0.3 0:00.09 top 346 root 20 0 2968 2060 1564 S 0.7 0.2 2:17.19 dhcpcd 17101 root 0 -20 0 0 0 I 0.7 0.0 2:49.94 kworker/0:1H-mmc_complete 10 root 20 0 0 0 0 I 0.3 0.0 7:00.05 rcu_sched 18 root 0 -20 0 0 0 I 0.3 0.0 4:21.89 kworker/1:0H-kblockd 83 root 0 -20 0 0 0 I 0.3 0.0 4:24.37 kworker/2:1H-kblockd 412 root 20 0 31976 9496 8068 S 0.3 1.0 0:29.19 nmbd |
于是很想了解这货在干嘛，消耗这么多脑力，思考人生么？
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
➜ ~ sudo lsof -p 345 lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME snapd 345 root cwd DIR 179,2 4096 2 / snapd 345 root rtd DIR 179,2 4096 2 / snapd 345 root txt REG 7,0 13421332 7147 /snap/core/9291/usr/lib/snapd/snapd snapd 345 root mem REG 179,2 1296004 2022 /lib/arm-linux-gnueabihf/libc-2.28.so snapd 345 root mem REG 179,2 130416 2085 /lib/arm-linux-gnueabihf/libpthread-2.28.so snapd 345 root mem REG 179,2 17708 10917 /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so snapd 345 root mem REG 179,2 138604 1945 /lib/arm-linux-gnueabihf/ld-2.28.so snapd 345 root 0r CHR 1,3 0t0 1028 /dev/null snapd 345 root 1u unix 0xf31a5a4c 0t0 14576 type=STREAM snapd 345 root 2u unix 0xf31a5a4c 0t0 14576 type=STREAM snapd 345 root 3u IPv4 152109 0t0 TCP 192.168.50.127:48604->api.snapcraft.io:https (ESTABLISHED) snapd 345 root 4u IPv4 233503 0t0 TCP 192.168.50.127:40786->api.snapcraft.io:https (ESTABLISHED) snapd 345 root 6u a_inode 0,11 0 5804 [eventpoll] snapd 345 root 7u unix 0x5b752603 0t0 14350 /run/snapd.socket type=STREAM snapd 345 root 8u unix 0xfebd686d 0t0 14353 /run/snapd-snap.socket type=STREAM snapd 345 root 9u REG 179,2 0 386387 /var/lib/snapd/snaps/core_9668.snap.partial snapd 345 root 12u netlink 0t0 18728 KOBJECT_UEVENT snapd 345 root 13r FIFO 0,10 0t0 18729 pipe snapd 345 root 14w FIFO 0,10 0t0 18729 pipe |
看起来是想回家拉点什么私货回来（api.snapcraft.io），但还是搞不懂，走io就走io，连续几天24小时一直吃那么多cpu是什么鬼？
完整阅读本篇»Powered by WordPress | 京ICP备17001541号-1 | 
京公网安备 11011502004657号
