分类 折腾=-= 下的文章

当你感到睡眠会打断你持续摄入使大脑兴奋的刺激时,你有权选择违背健康原则拒绝休息。
顺便,还可以点一杯奶茶,恩令你加倍愉悦。🥰
一个21世纪的人应该永远留给自己放纵的权利。————本博主

首先解决了一下证书问题,证书现在由acme.sh正确管理,并且使用了一个脚本确保证书文件被同步到pmail的配置路径。
然后刚修好就看见日志里不停歇的撞库.....难绷啊

最后,祝大家阖家团圆,中秋快乐!

2025年10月7日02点22分

把家里和RN的Debian服务器BBR都启用了(我启用之前完全没想到我之前竟然用的cubic),算法选择: fq_codel

sudo nano /etc/sysctl.conf
net.core.default_qdisc=fq_codel
net.ipv4.tcp_congestion_control=bbr
#别忘了
sysctl -p 

如果是Fedora的桌面PC,应该更标准点修改: /etc/sysctl.d/99-sysctl.conf

这样应该可以一定程度上减少运营商对上行的恶意限制,尽可能跑满实际最大上行。
吃的好饱,嗝~

找到问题真正的元凶

早先我发了一篇文章【避雷!】别买QLC垃圾盘,下载进去就损坏!但是现在我发现问题并不像我想的那么简单,通过CrystalDiskInfo我发现INTEL SSDPEKNU512GZ : 512.1 GB 健康状态并无异常。

CrystalDiskInfo_20250824181711.png
而且在迁移游戏文件到致钛后,昨天游玩时仍然出现了错误:逃离塔科夫进入战局前校验文件失败自动弹出了游戏并且启动器要求校验并修复损坏文件。游玩时电脑还时不时突然关机重启,有时候是软重启有时候是硬重启。
这意味着,肯定有什么别的东西坏掉了。 第一时间我就开始怀疑内存有问题,这是和频繁的蓝屏重启后的错误代码:MEMORY_MANAGEMENT 对应的。

今天早上使用MemTest64.exe 进行了内存测试,最终确定问题的确在DRAM上:
第一次测试很快结束并没有任何问题,
2025-08-24T10:25:02.png
但是第二次测试进行时WIndows11直接崩溃重启了。
在随后的测试里,不断有黑屏等问题出现,校验出现错误非常多,下图是我在编写本文时随手再次测试的并很快手动中止的,因此显示的错误数量远不及早上长达20分钟的反复测试:
2025-08-24T10:29:30.png

售后处理

这两根内存是在2024年七月份购买的,到现在只使用了一年。
在淘宝联系光威客服后,客服表示内存提供终身质保,售后需要发回广州。如果已经停产没有同型号的备件会调换其他同类型产品,但是可能花费更多时间。花费时间在三天到数星期不等。 因为超过了3个月运费是各付各的。
作为出门在外的打工人,只能说这太tm烦人了,因为我手头根本没有其他内存条可以临时替代,也就是说我在拆下内存发走后电脑就别想开机了。
2025-08-24T10:39:49.png
目前已经在淘宝花了十五块随便买了一套螺丝刀,希望问题尽早解决,该死的浪费的全是我宝贵的休息时间啊。

2025年8月27日更新:这两根内存条似乎对温度比较敏感

我昨晚就运行了Windows内存测试工具跑了一晚上,结果是确实有问题。但是今天早上下班后的游戏过程中并没有发现异常,而且MemTest64的短时间测试也完全没有发现任何如同之前的error。
这些测试中唯一不同的就是我今天游戏时使用了机械革命的狂飙模式。
性能和风扇RPM成正比,且性能上办公模式<游戏模式<狂飙模式
螺丝刀已经到了,我决定继续观察,暂时不急着返厂更换内存条了。
在睡觉之前,我把MemTest64打开继续进行6个小时的测试,空调环境温度设置24摄氏度,笔记本设置游戏模式
zZ``

昨天逃离塔克夫服务器停机更新,没玩成去打GO了。今天下班就开始重装WIndows+更新塔科夫,结果发现我下载进原机硬盘的游戏文件更新时校验不通过,浪费数个小时连续重复三次之后我完全确定这和硬盘有关系了。
那块有问题的硬盘:

产品 英特尔 SSDPEKNU512GZ (固态硬盘)
大小 512 GB
固件 002C
接口 PCIe 3.0 x4
数据传输率 4000 MB/秒
特性 S.M.A.R.T, TRIM, VolatileWriteCache
硬盘已使用 共 3923 次,累计 5115 小时

然后我把战地1从致钛7100丢了过去腾出空间,再把游戏重新下进致钛,下载完成终于是没问题,太逆天了该死的垃圾QLC盘,这下存游戏也不太合适了。

前段时间我去爬山,回来写了文章:朱雀国家森林公园痛苦一日游
上传图片的时候发现当前时代的浏览器并不支持浏览HEIF格式的图片,但是这一标准在苹果和许多较新安卓设备上都已经开始推广,并且压缩率不错,所以能不能想办法让浏览器显示HEIF格式的图片呢?

找到所需开源项目:

hoppergee/heic-to Convert HEIC/HEIF images to JPEG, PNG in browser
我的需求显然早就有人在做了,这个项目利用javascript提供了一个在前端将HEIF格式图片转换成jpeg/png的方案。

引用heic-to

工作原理:

  1. 自动检测所有带有.heic或.HEIC扩展名的图片
  2. 使用fetch API获取原始HEIC文件
  3. 在浏览器中转换为JPEG格式
  4. 替换图片的src属性显示转换后的图片
<script type="module">
// 导入CSP安全版本的HEIC转换模块 需要支持ES6特性
import { heicTo } from 'https://cdn.jsdelivr.net/npm/[email protected]/dist/csp/heic-to.js';

document.addEventListener('DOMContentLoaded', async function() {
    // 检查浏览器是否支持所需API
    if (!window.fetch || !window.URL || !window.Blob) {
        console.warn('浏览器不支持HEIC转换所需API');
        return;
    }
    
    // 处理HEIC图片转换
    async function processHEICImages() {
        const images = document.querySelectorAll('img[src$=".heic"], img[src$=".HEIC"]');
        if (images.length === 0) return;
        
        console.log(`找到 ${images.length} 张HEIC图片,开始转换...`);
        
        for (const img of images) {
            const src = img.src;
            const originalAlt = img.alt || '';
            const originalClass = img.className;
            
            try {
                // 添加加载状态
                img.alt = 'HEIC图片转换中...';
                img.classList.add('heic-loading');
                
                // 获取HEIC文件
                const response = await fetch(src);
                if (!response.ok) throw new Error(`HTTP错误! 状态码: ${response.status}`);
                
                const blob = await response.blob();
                
                // 转换为JPEG
                const jpegBlob = await heicTo({
                    blob: blob,
                    type: "image/jpeg",
                    quality: 0.8
                });
                
                // 创建对象URL并替换
                const jpegUrl = URL.createObjectURL(jpegBlob);
                img.onload = function() {
                    URL.revokeObjectURL(jpegUrl); // 释放内存
                    img.classList.remove('heic-loading');
                    img.classList.add('heic-converted');
                };
                img.src = jpegUrl;
                img.alt = originalAlt;
                img.className = originalClass;

            } catch (err) {
                console.error('HEIC转换失败:', err);
                img.alt = originalAlt + ' [HEIC转换失败]';
                img.classList.remove('heic-loading');
                img.classList.add('heic-error');
            }
        }
    }
    
    await processHEICImages();
});
</script>

<style>
.heic-loading {
    position: relative;
    min-height: 100px;
    background: #f5f5f5 url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"><circle cx="50" cy="50" r="40" stroke="%233498db" stroke-width="8" fill="none" stroke-dasharray="62.8 188.8"><animateTransform attributeName="transform" type="rotate" repeatCount="indefinite" dur="1s" values="0 50 50;360 50 50" keyTimes="0;1"></animateTransform></circle></svg>') no-repeat center;
    background-size: 50px;
}
.heic-converted {
    border: 2px solid #2ecc71;
}
.heic-error {
    border: 2px dashed #e74c3c;
}
</style>

使用方法:

你可以引用上面的代码到任意html页面,通常我们把他放在header或footer里。
在Typecho上我们可以把它放在主题文件的: header.php 中

本文代码已在Github以MIT协议开源,感谢自由软件与开源社区!
DisplayMyHEIC

测试图片

测试图片1-人物
测试图片2-缆车

作者: 未知狐 时间: 2025-3-22 分类: 随手记,Linux,折腾=-=
我,人在西安,它,宕在郑州。
人已麻。
没事别动/etc/fstab ,有事也别tm动。
预计下次回家才能修,那就已经是清明节了,啊啊啊啊啊啊。

2025年4月5日更新
经过清明节至今天凌晨的抢修已彻底恢复 nas.xfox.fun和LinuxUse.site的反代。
同时,今后Frp将仅用作防失联的措施之一,不作为任何服务的主要对外访问渠道。
上述所有站永久切入HK三网优化线路,不再使用第三方反代业务。

顺带一提,修复排查的时候用了DeepSeek R1 和V3 但是发现回答会受到输入的错误配置文件的干扰使其产生幻觉。
所以我建议如果你想偷懒,最好让AI重新写配置文件而不是输入可能存在问题的配置信息让他修改。
Momo5418
2025年4月5日21:39
在学校配置家里软路由的nginx搞得端口占用了,访问后台直接403,本打算回家弄,结果回到家它自己好了。

回复
未知狐未知狐
2025年4月5日22:57
我猜是nginx启动了占用了80/443又没有配置对后台管理Web服务反代 导致无法访问,回家的时候nginx又因为没有设置Systemd保活 down了,于是乎后台又能正常访问了。

回复
GoodBoyboyGoodBoyboy
2025年3月23日17:03
这些高风险操作我向来是不敢远程弄的,怕一个reboot后就再也连不上ssh了😂

回复
未知狐未知狐
2025年3月23日19:02
我还是大意了,无所谓了,暂时也不用往NAS上放什么东西,等有空回家了再修,我已经远程关电了。

回复
EricQwQEricQwQ
2025年3月28日0:09
emmm遠程開機也救不了嗎

回复
未知狐未知狐
2025年3月29日16:13
会挂载不上盘,直接卡在开机过程。索性直接远程拔电了。

=-=本来不想去的,但是工友盛情难却还是在周六窜出去了。
爬山,累得半死,回来肌肉酸痛那叫一个酸爽。当然,出于被忽悠去爬山的报复心理,我拉着他俩不坐缆车硬腿上去,又腿下来,只有临走的时候时间太晚了我也懒得折腾了才花20块钱买了张景区内的载客观光车加速回到起点。
不知道当时脑子是不是在厂里干活干多了坏掉了,出去的时候没提前做防晒,戴着鸭舌帽穿着短T就冲了。
回来发现裸露的肢体直接就是一个晒伤,皮肤红的跟大虾一样,一接触阳光或外力刺激就有刺痛感。
就在写本文的时候又感觉胳膊晒伤的位置瘙痒难耐,可能是皮肤组织的炎症反应。
罢了罢了,吃点维生素C+复合B硬抗吧,自限性疾病又没什么特效药...唉。

8月5日

洗澡的时候发现胳膊晒伤的区域起皮了,看来损伤的皮肤正在缓慢修复。

照片

我GFPGAN1.4修复2025-08-07T09:19:28.png
工友拍的有点难绷,以后一定要自己买个大疆好拍照,只有自己才知道自己想拍成什么样。
下面是我拍的。
场内车票
下面是一张HEIC图片,根据在博客上无障碍浏览HEIC/HEIF图片我已经给博客添加了用于转换HEIF格式到浏览器可显示的图片格式的代码,理论上你可以在大部分现代浏览器上浏览下面这张图片。
两位工友-HEIC测试图片
由于Chromium目前还不支持HEIC图片所以你可能需要下载才能看。不过,你可以通过我的NAS浏览这些照片。
NAS预览
密码xfox.fun

https://web.archive.org/web/20250416075550/https://xfox.fun/archives/2088/ 恢复
作者: 未知狐 时间: 2025-3-22 分类: 随手记,Linux,时间轴,折腾=-=
购买新的服务器后,我也不打算继续续费sakurafrp了,所以反代提供公网IPv4访问的工作需要转移到Claw HK机上,同样地Mumble服务器的IPv4转发也需要迁移到Claw HK机器上。
除了博客本身直接部署,所有需要反代,转发的服务都通过WireGuard组网后虚拟局域网转发完成。

Nginx反代配置

nas.xfox.fun

# HTTPS 强制跳转配置
server {
    listen 80;
    listen [::]:80;
    server_name nas.xfox.fun;
    return 301 https://$host$request_uri;
}

# 主 HTTPS 服务配置
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name nas.xfox.fun;

    # 更新后的SSL证书路径
    ssl_certificate /home/xfox/www/all_xfox.fun/fullchain.pem;
    ssl_certificate_key /home/xfox/www/all_xfox.fun/privkey.pem;

    # SSL 优化配置
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;
    add_header Strict-Transport-Security "max-age=63072000" always;

    # 反向代理配置
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        
        proxy_redirect off;
        proxy_pass http://10.10.0.2:5212;

        # 超大文件支持 client_max_body_size 缺省单位->字节 ,k千字节,m兆字节,g千兆字节
        client_max_body_size 16g;
        proxy_request_buffering off;
        proxy_buffering off;
    }
}

Mumble IPv4转发 && 数据库与配置文件同步

我尝试使用iptables转发失败了,然后换了nftables还是失败了,懒得折腾了。
直接把Mumble服务器也迁移到Claw HK上。
后续直接写脚本同步数据库和配置文件。

Mumble数据库和配置文件
两个属于root的文件:

-rwxrwxrwx 1 root root 16K 12月16日 20:26 /etc/mumble-server.ini
-rwxrwxrwx 1 root root 1016K  3月22日 16:06 /var/lib/mumble-server/mumble-server.sqlite

接下来先把家庭服务器的Mumble服务器配置同步到ClawHK服务器

# 同步配置文件
sudo rsync -avz -e "ssh -i /home/xfox/.ssh/id_ed25519 -o StrictHostKeyChecking=no" \
  /etc/mumble-server.ini \
  [email protected]:/etc/

# 同步数据库文件
sudo rsync -avz -e "ssh -i /home/xfox/.ssh/id_ed25519 -o StrictHostKeyChecking=no" \
  /var/lib/mumble-server/mumble-server.sqlite \
  [email protected]:/var/lib/mumble-server/

启动Mumble服务器发现:
Mar 22 09:58:29 ClawHK mumble-server[50320]: 2025-03-22 09:58:29.869 Initializing settings from /etc/mumble-server.ini (basepath /etc)
Mar 22 09:58:29 ClawHK mumble-server[50320]: 2025-03-22 09:58:29.870 MetaParams: Failed to read /home/xfox/www/all_xfox.fun/fullchain.pem
看上去Mumble-server没权限读取证书。

sudo chmod +x /home/xfox /home/xfox/www /home/xfox/www/all_xfox.fun

即可。

仅有一条评论
EricQwQEricQwQ
2025年3月28日0:17
sakurafrp還是不錯的…免費版真香,主要是穩定+方便

回复

应用选型:Mailu

Mailu项目仓库

架构规划

主要设备

服务器名称硬件网络用途
境内Server AEliteDesk800G3 SSF ,G4600,2*8GB RAM无公网IP运行mailu 容器
境外Server BRackNerd VPS,1*Vcpu,768MB RAM有公网IP提供公网IPv4 地址

网络规划

考虑到方案1可能违反SakuraFrp的用户协议,暂定方案2。

方案实施风险
方案1在A上运行FRP,开出公网端口用于与B的通信;在B上运行socat转发必要端口到A,实现A-B双向通信。依赖第三方服务(如FRP)的稳定性,可能存在性能瓶颈或配置复杂性。
方案2在A、B上运行WireGuard,实现10.10.0.0/24虚拟组网。配置较为复杂,涉及跨境组网,网络波动可能导致通信失败。

- 阅读剩余部分 -