Ysicing | 缘生的 RSS 预览

Tailscale Peer Relay 最新变更解读

2025-12-11 22:50:34

在我之前的文章 Tailscale Peer Relay 实战指南，让内网穿透更稳更快中，我介绍了如何通过在 Tailnet 内配置一台网络条件良好的设备作为中继，来优化内网穿透体验。最近 Tailscale 官方对 Peer Relay 做出了重要更新，尤其是 新增支持 Static Endpoints，这是一次值得关注的变化。

核心更新一览

新增 Static Endpoints
- 过去：Peer Relay 只能依赖 Tailnet 内的某个设备作为中继，设备必须在线。
- 现在：支持配置 固定的中继地址（Static Endpoint），例如云服务器或数据中心节点。
- 意义：让 Peer Relay 从“临时设备中继”升级为“可控的固定中继”，更稳定、更适合企业和高吞吐场景。
官方定位调整
- 旧理解：Peer Relay 可以替代 DERP。
- 新定位：Peer Relay 是 DERP 的补充，在直连失败时优先尝试，如果不可用仍会回退到 DERP。
- 这意味着 DERP 依旧是兜底方案，而 Peer Relay 更像是加速器。
权限与安全控制
- 官方强调避免过度宽泛的 ACL 配置（如 src: *），否则可能导致所有设备都走中继，增加延迟。
- 最佳实践：只针对受限环境或特定标签设备开放 Peer Relay/Static Endpoint。

配置与验证方式

启用命令保持一致：

tailscale set --relay-server-port=40000

ACL 中新增写法：

{
  "grants": [
    {
      "src": ["tag:restricted-devices"],
      "dst": ["static:relay.example.com:40000"],
      "app": { "tailscale.com/cap/relay": [] }
    }
  ]
}

验证方式：除了 tailscale ping，还可以用
```
tailscale status | grep peer-relay
```
来确认连接是否走中继。

典型应用场景
- 大文件传输：提升吞吐，避免 DERP 带宽瓶颈。
- 媒体流播放：高清视频/音频流更流畅。
- 区域优化：在不同地理位置部署静态中继，降低跨区延迟。
禁用

tailscale set --relay-server-port=""

总结

这次更新的最大亮点就是 Static Endpoints 的支持，让 Peer Relay 从“设备中继”走向“固定中继”，更适合企业和高吞吐场景。同时，官方也明确了 Peer Relay 的定位——它是 DERP 的补充，而不是替代。

如果你之前已经部署过 Peer Relay，现在可以考虑在云端或数据中心配置一个 Static Endpoint，让整个 Tailnet 的中继更加稳定和可控。

Umami 升级提醒：尽快更新以修复 Next.js CVE-2025-66478 漏洞

2025-12-06 01:17:27

最近 Next.js 官方发布了 CVE-2025-66478 安全公告（详情可见官方链接）。由于 Umami 采用 Next.js 构建，因此同样受到本次漏洞影响

好消息是：Umami 官方已经发布新版本修复漏洞

同时需要注意：Umami 从 v3 起彻底移除 MySQL 支持，统一切换为 PostgreSQL
如果你仍在使用 MySQL 版本，强烈建议你尽快升级并迁移数据，避免暴露在风险中

v2 升级到最新版本

我已经同步好了官方镜像, 替换直接升级，由于 v2 版本没有打 patch 只能升级到 v3 才能解决

- ghcr.io/umami-software/umami:mysql-latest
- ccr.ccs.tencentyun.com/k7scn/umami:mysql-latest

将 MySQL 迁移到 PostgreSQL

Umami v3 确保数据的一致性，废弃了对 mysql 的支持，统一采用 PostgreSQL。本步骤参考官方文档 install-umami-with-a-postgresql-database 实践。

升级真是一件糟糕的体验，如果你之前是使用 MySQL，不建议升级，直接重装 v3

环境要求

官方要求迁移前 MySQL 结构必须达到 v2.19.0，否则执行迁移脚本会失败
你可以通过升级镜像确保数据库 schema 是最新的

两个数据库的登录凭证：

MySQL: mysql://user:password@host:port/dbname
PostgreSQL: postgresql://user:password@host:port/dbname

PG 数据库

bitnami 操作也很蜜汁。如下示例，对应 ip 密码自行修改

services:
  postgresql:
    image: h.ysicing.net/bitnami/postgresql
    container_name: postgresql
    ports:
      - '100.90.80.10:5432:5432'
    volumes:
      - '/data/postgresql:/bitnami/postgresql'
    environment:
      - POSTGRESQL_DATABASE=umami
      - POSTGRESQL_USERNAME=user
      - POSTGRESQL_PASSWORD=password
      - POSTGRESQL_POSTGRES_PASSWORD=password_root
    restart: always

导出 mysql 数据

mysqldump --no-create-info --default-character-set=utf8mb4 --quick --skip-add-locks -uroot -h100.90.80.10 -poAkahz4ahvei1oReing6oh5ubaen1veV umami > umami.sql

部署 pg 版 Umami v2

具体参考流程可以参考部署轻量数据统计分析 umami

官方镜像 ghcr.io/umami-software/umami:postgresql-v2
国内镜像 ccr.ccs.tencentyun.com/k7scn/umami:postgresql-v2

替换一下镜像地址和环境变量

mysql 环境变量为

- env:
        - name: DATABASE_URL
          value: mysql://root:[email protected]:3306/umami
        - name: HASH_SALT
          value: ezee4eGhalaishiphese8yaiphomon
        - name: DATABASE_TYPE
          value: mysql
        image: ccr.ccs.tencentyun.com/k7scn/umami:mysql-latest

pg 环境变量为

- env:
        - name: DATABASE_URL
          value: postgresql://ysicing:[email protected]:5432/umami
        - name: HASH_SALT
          value: ezee4eGhalaishiphese8yaiphomon
        image: ccr.ccs.tencentyun.com/k7scn/umami:postgresql-v2

去掉了 DATABASE_TYPE, 修改了 DATABASE_URL 值
镜像换成了 pg v2 版本镜像

等初始化完成，关闭服务，避免重复初始化数据库(避免影响下面流程)

修改 pg 数据库

使用 DataGrip 连接 umami 数据库，执行下面的 sql，这两个表数据将从 mysql 的数据中获取

truncate table "_prisma_migrations";
truncate table "user";

效果如下

[2025-12-05 22:24:47] 已连接到 umami
[2025-12-05 22:24:47] umami> truncate table "_prisma_migrations"
[2025-12-05 22:24:47] 在 10 ms 内完成
[2025-12-05 22:24:47] umami> truncate table "user"
[2025-12-05 22:24:47] 在 11 ms 内完成

导入数据

使用上面的备份数据 umami.sql

22:22 ➜  ~ ls -alh umami.sql
-rw-r--r--  1 ysicing  staff    99M 12  5 22:09 umami.sql

将反引号替换为双引号，使其与 PostgreSQL 兼容, 如果 macOS 执行有问题，在 Linux 搞下。操作前可以备份一下，避免搞坏了

sed -i 's/`/"/g' umami.sql

macOS

sed -i '' 's/`//g' umami.sql
sed -i '' 's/\\"/"/g' umami.sql
sed -i '' "s/\\\\'/'/g" umami.sql
sed -i '' "s/Xi'an/Xi''an/g" umami.sql
sed -i '' "s/Lu'an/Lu''an/g" umami.sql
sed -i '' "s/Ma'anshan/Ma''anshan/g" umami.sql
sed -i '' "s/Rui'an/Rui''an/g" umami.sql
sed -i '' "s/Yu'an/Yu''an/g" umami.sql
sed -i '' "s/Bo'an/Bo''an/g" umami.sql
sed -i '' "s/Tai'an/Tai''an/g" umami.sql
sed -i '' "s/Cao'an/Cao''an/g" umami.sql
sed -i '' "s/Chang'an/Chang''an/g" umami.sql
sed -i '' 's/ENGINE=[^ ]*//g' umami.sql
sed -i '' 's/AUTO_INCREMENT/[generated always as identity]/g' umami.sql
sed -i '' 's/unsigned//g' umami.sql
sed -i '' '/_prisma_migrations/d' umami.sql

可以手搓如下，我这里直接使用 DataGrip

psql -U username -d mydb < umami.sql

由于 MySQL → PostgreSQL 差异巨大，需要执行大量替换操作。报错太多，决定放弃升级改成使用 v3 版本, 还是重装方便

v3 版本镜像

由于兼容性问题太多，我最终选择放弃 v2 的 MySQL → PostgreSQL 迁移，转而直接部署全新的 Umami v3。

v3 镜像地址：

官方：ghcr.io/umami-software/umami:postgresql-latest
国内同步：ccr.ccs.tencentyun.com/k7scn/umami:postgresql-latest

v3 使用体验更流畅、性能也更好，而且完全修复了此次 Next.js 漏洞。

总结：请大家尽快升级，避免被入侵

Umami 因 Next.js 漏洞受到影响

v3 已发布修复版本
强烈建议优先考虑升级至 v3
MySQL 用户请务必注意：v3 不再支持 MySQL

如果你还在运行旧版本，请尽快升级，避免站点暴露在风险中！我今天至少已经看到 10+ 站点被入侵挂马了。

出一台闲置的物理服务器

2025-12-02 22:35:49

很早之前我出的，然后又被我收到了，现在又闲置了，打算出了

厂家

老牌 IDC 了，工单响应速度极快，即使凌晨 15 分钟接单。

机器配置

Platinum8259CL*2
128GB DDR4
1TB NVMe SSD

续费 358/月
带宽上限 50Mbps (上行是 50Mbps，下行是 150Mbps)
防护峰值 400Gbps

迁移至宁波电信需在账单日进行且该机器为十堰活动款，迁移至宁波地区您的续费价格将会上调至 398 元，需要实名的。

12.19 到期, 一口价 300，需要自备实名账号，有意可以私聊我。

k8s免密拉取镜像实践

2025-12-01 22:09:17

算是一个比较老的知识点了 😂

之前都是使用云服务商提供的免密凭证，最近需要跨云跨账号，使用 AI 自己实现了一个通用的

原理

借助 ServiceAccount，实现 Pod 自动免密拉取私有镜像，做到镜像凭据配置一次，全命名空间或指定应用自动生效

主要优势

一个 ns 空间下只需要配置一次 secrets。Kubernetes 拉取私有镜像需要认证信息。如果每个服务都写 imagePullSecrets，不仅配置冗余，也不利于权限统一管理

使用 ServiceAccount 可以带来两个好处：

配置一次，全自动继承
不污染 Pod 等 yaml，让业务部署更干净

手动配置

主要参考官方文档为服务账号添加 ImagePullSecrets

首先，生成一个 imagePullSecret；接下来，验证该 Secret 已被创建。例如：

kubectl create secret docker-registry myregistrykey --docker-server=<registry name> \
        --docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \
        --docker-email=DUMMY_DOCKER_EMAIL
        
# 检查该 Secret 已经被创建
kubectl get secrets myregistrykey
NAME             TYPE                              DATA    AGE
myregistrykey    kubernetes.io/.dockerconfigjson   1       1d

将镜像拉取 Secret 添加到服务账号

接下来更改名字空间的默认服务账号，将该 Secret 用作 imagePullSecret

kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'

效果等同于

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2021-07-07T22:02:39Z
  name: default
  namespace: default
  uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
imagePullSecrets:
  - name: myregistrykey

再当前命名空间下创建一个私有仓库的 Pod 测试看看

自动实现

原理就是 watch ns 创建，当收到 ns 创建后，自动创建相关凭证，同时给 ns 打上凭证版本标签，方便后续凭证有更新。

其他

不建议把 secret 绑定到 default ServiceAccount，因为权限难以收敛，当然我是没听他的建议。

Z-Image-Turbo，快就完事了

2025-11-30 21:48:04

最近比较火的，可以 NSFW, 模型默认生成美女 😂
如果你正在寻找一款高性能、轻量、可灵活集成的图片处理方案，那么 Z-Image-Turbo 绝对值得重点关注

简介

Z-Image 是由阿里云通义万相团队推出的一款高效文生图 AI 模型，其核心优势在于 Turbo 级的极致推理速度，能够在秒级时间内将文本描述转化为高质量图像，完美平衡了生成效率与画质表现，极大提升了 AI 创作的实时交互体验

主要优势

极致推理速度 (Turbo 级) 核心特点是快。通过深度模型优化或技术蒸馏，显著减少了推理步数，实现秒级图像生成，极大提升了创作的实时性和交互感
速度与质量兼备 在追求极致速度的同时，保持了高水准的图像生成质量。它在快速出图和细节、结构、光影表现之间取得了优秀的平衡，产出图片具备实用价值
原生中文语境理解 继承了通义大模型家族强大的语言能力，对中文提示词（Prompt）及中国文化元素有深刻的理解，能更准确地还原中文用户的创作意图
低门槛 对计算资源的消耗相对较低，降低了开发者的使用和部署门槛，利于集成到各类实时应用中
NSFW

体验地址

可能被人大量生成 NSFW，目前官方 demo 已经禁止，自建是没限制的

Tongyi-MAI/Z-Image-Turbo

其他

其实类似教程 L 站也有不少，有兴趣可以搜搜。

Debian/Ubuntu 默认禁用 SSH RSA 密钥？一篇文章教你彻底解决

2025-11-28 22:25:29

最近升级了 Gitspace 基础环境版本，导致没法使用 RemoteSSH。

在新版本系统中，不少人发现原本一直使用的 RSA SSH Key 突然无法登录了。原因不是你的服务器出了问题，而是 OpenSSH 在 8.3 版本之后，默认关闭了对 ssh-rsa 的支持。

本文带你快速了解为什么会这样、怎样安全地重新启用 RSA Key 登录，以及需要注意哪些风险和最佳实践。全文简单易懂、一步到位。

RSA 过时协议

OpenSSH 官方从 8.3 起，将 ssh-rsa 标记为过时算法，主要原因是：

RSA（尤其是小于 4096 位的）安全性相对较弱
更现代、更高强度的算法例如 ed25519、ecdsa 已经普及
出于安全考虑，服务器端默认不再接受 ssh-rsa 签名

因此，在看到日志类似：

Authentications that can continue: publickey,password
Trying private key: /root/.ssh/id_rsa

之前免密配置了但就是死活登录不上

注意：客户端其实仍然可以使用 RSA，只不过是服务器拒绝了它

大多数情况下，客户端不用配置任何内容，因为 OpenSSH 客户端默认依然支持 RSA
真正需要修改的是服务器，因为服务器默认不接受 ssh-rsa 公钥

当然还有少数情况下客户端也需要配置，我就是改出问题了，客户端也需要配置

重新启用 RSA Key 登录

为了避免修改主配置文件 sshd_config 被升级覆盖，我们使用新版本系统推荐的配置目录 /etc/ssh/sshd_config.d

sudo tee /etc/ssh/sshd_config.d/enable_rsa_keys.conf > /dev/null << EOF
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
EOF

然后重启 ssh 服务

sudo systemctl restart ssh
或
sudo systemctl restart sshd

到这里，服务器已恢复对 RSA Key 的支持。

如果已经执行了这个，还不行就需要配置客户端了

# ~/.ssh/config
Host *
	User root
	ServerAliveInterval 60
	ForwardAgent yes
	TCPKeepAlive no
	ControlMaster auto
	ControlPath ~/.ssh/tmp/connection-%r@%h:%p
	ControlPersist 1h
	Compression yes
	HostkeyAlgorithms +ssh-rsa
	PubkeyAcceptedKeyTypes +ssh-rsa

如果没有 SSH 密钥

ssh-keygen -t rsa -b 4096
或者 默认 -a是16
ssh-keygen -t ed25519 -a 100

其他

只在必要场景下开启 RSA，新的环境更推荐 ed25519

Ysicing | 缘生修改