👀我的gpg证书更新了，诸位别用旧的发信。
最新公钥地址保持原链接不变
https://xfox.fun/usr/uploads/2022/10/1276553138.asc
再过几天我会彻底吊销旧证书。
这次更新是对RSA 4096未来安全性下降做出的提前准备，新证书使用Curve25519算法，本次更新后未来较长时间不会再进行更新

新证书的信息：

这个想法自从我开始使用Pmail就有了但是一直因为各种原因没有实现。

初步预期

尽可能在不额外进行训练/微调的情况下使用RWKV（这我熟啊.webp)的小体积模型结合提示词与预设上下文对输入邮件进行处理返回一个带有概率值的JSON数值，该数值将作为入站邮件处理API的返回值传递给Pmail。
最终达到在较低算力及内存资源的边缘设备（如自组NAS）上完成对个人或小组织级别邮件服务的垃圾邮件处理。

数据结构

为了便于Pmail使用，请求格式及返回值按照：PMail/server/hooks/spam_block/的数据结构：
请求：

curl -X POST http://localhost:8501/v1/models/emotion_model:predict -d '{ 
    "instances": [
        {"token":["各位同事请注意 这里是110，请大家立刻把银行卡账号密码回复发给我！"]}
    ]
}' 

输出：

{
  "predictions": [
    [
      0.394376636,
      // 正常邮件的得分
      0.0055413493,
      // 广告邮件的得分
      0.633584619
      // 诈骗邮件的得分，这里诈骗邮件得分最高，因此最可能为诈骗邮件
    ]
  ]
}

静域信驿

静域信驿（Tranquil Inbox Ward）
静域信驿（Tranquil Inbox Ward），专为 pmail 设计的关键词增强型垃圾邮件分类服务（规则 + LLM 混合）。
扒拉邮箱的垃圾邮件测试了很久，还是决定使用关键词加权结合LLM分类完成，因为测试发现较小的模型分类效果尚可，但直接要求给出三个分类各自的期望值效果就很差，即便使用较大规模的模型也难以通过提示词达到预期效果。（也可能我提示词写太烂....sad)按照项目预期，我打算让他跑在NAS的集成显卡上而不是AI性能更显羸弱的CPU上，这就要求必须尽可能使用更小体量的模型。
目前还有很多乱七八糟的问题，需要慢慢发现并解决，当然————欢迎PR

报错如下：

root@racknerd-14a7c8:~# podman stop pmail
2025-10-19T09:53:14.285697Z: send signal to pidfd: Permission denied
Error: timed out waiting for file /run/libpod/exits/b0fc27c2e04e4655bc2a810ce522b37952f27b4706727bbca2f9faa59de150b3: internal libpod error

并且使用podman-compose down也会有相同报错，并且重启容器时会遇到残留进程占用25端口的问题。
在经过一系列尝试后DeepSeek已经开始不断推荐我直接使用Docker，但是我不想用。所以尝试使用runc作为最后一搏，还不行我就真的换Docker了，毕竟好用的工具才是好工具。

什么是RunC？

RunC是Docker捐赠给OCI作为OCI容器运行时标准的参考实现，因此我猜想使用runc比podman的默认运行方式更符合OCI标准，因而能更大程度兼容Docker镜像。
安装 runc sudo apt install runc -y

配置 Podman 使用 runc 作为默认运行时

sudo nano /etc/containers/containers.conf
在 containers.conf 中添加：

[engine]
runtime = "runc"

为了确保podman-compose一定使用了runc，可以添加runtime: runc

version: '3'
services:
  pmail:
    image: ghcr.io/jinnrry/pmail:latest
    container_name: pmail
    restart: always
    #privileged: true 特权运行不能解决当前遇到的问题，所以没必要用。
    ports:
      - "25:25"
      - "2080:80"
      - "20443:443"
      - "110:110"
      - "465:465"
      - "995:995"
      - "993:993"
    volumes:
      - "/root/podman/pmail/config:/work/config"
    runtime: runc

这时候再使用podman-compose up -d和down 应该都问题了。
但是你最好确保自己的环境是完全干净的，可以通过：
podman system reset --force && reboot 确保这点。

当你感到睡眠会打断你持续摄入使大脑兴奋的刺激时，你有权选择违背健康原则拒绝休息。
顺便，还可以点一杯奶茶，恩令你加倍愉悦。🥰
一个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

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

前段时间我去爬山，回来写了文章：朱雀国家森林公园痛苦一日游
上传图片的时候发现当前时代的浏览器并不支持浏览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/heic-to@1.2.1/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

测试图片

作者: 未知狐 时间: 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
会挂载不上盘，直接卡在开机过程。索性直接远程拔电了。

从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 \
  root@10.10.0.1:/etc/

# 同步数据库文件
sudo rsync -avz -e "ssh -i /home/xfox/.ssh/id_ed25519 -o StrictHostKeyChecking=no" \
  /var/lib/mumble-server/mumble-server.sqlite \
  root@10.10.0.1:/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项目仓库

架构规划

主要设备

网络规划

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

- 阅读剩余部分 -