Mental Studio

OpenClaw的安装与使用

Sat, 14 Feb 2026 19:30:00 +0800

本文由deepseek提供辅助编写

OpenClaw简介

最近这个龙虾机器人很红，最早是叫ClawBot，后来被Claude告了，改成MoltBot，然后又改成现在的OpenClaw。

主要特性:

支持多个AI模型接入(OpenAI、Claude、等)
多渠道消息推送(Telegram、钉钉、企业微信等)
插件化架构,易于扩展
支持对话上下文管理
Docker部署支持
配置简单,开箱即用

安装OpenClaw

准备工作

需要准备一台配置为2C2G或更高的虚拟机, 确保虚拟机有外网访问权限。系统为Linux，这里以Debian13为例。

安装步骤

使用官方一键安装脚本安装OpenClaw:

curl -fsSL https://openclaw.ai/install.sh | bash

建议使用当前用户安装，如果用root用户安装可以有更大的权限，但也有更大的风险。

安装过程中需要配置AI接口，如果你有OpenAI或Claude的API直接配置上去就好了，早年Deepseek没有在支持列表里，需要后面再配，这里只能先跳过，现在版本已经支持了。

安装过程中如果有问题，可以再次安装

# 完全重装
openclaw setup
# 安装后的设置
openclaw onboard

如果openclaw命令不能使用，可能需要重新登录一下当前用户。如果登录后还不行，则需要再次运行一键安装脚本。

配置DeepSeek API

DeepSeek是国内优秀的AI模型提供商,提供免费和付费的API服务。OpenClaw支持对接DeepSeek API,配置方式与OpenAI类似。

1. 获取DeepSeek API Key

访问DeepSeek官网: https://platform.deepseek.com
注册账号并登录
进入API Keys页面
点击"Create new API Key"创建新的API密钥
保存生成的API Key

2. 配置OpenClaw使用DeepSeek

编辑OpenClaw配置文件:

vim ~/.openclaw/openclaw.json

修改AI配置部分:

"models": {
  "providers": {
    "deepseek": {
      "baseUrl": "https://api.deepseek.com/v1",  # DeepSeek API地址
      "apiKey": "你的DeepSeek API Key",
      "auth": "api-key",
      "api": "openai-completions",
      "models": [
        {
          "id": "deepseek-v4-flase",
          "name": "Deepseek V4 Flash",
          "contextWindow": 1048576,
          "maxTokens": 16384
        }
        {
          "id": "deepseek-v4-pro",
          "name": "Deepseek V4 Pro",
          "contextWindow": 1048576,
          "maxTokens": 16384
        }
      ]
    }
  }
}

4. 测试DeepSeek API

重启OpenClaw服务后,发送测试消息:

systemctl --user restart openclaw
# 或
openclaw gateway restart

在Telegram或钉钉中发送消息,OpenClaw会使用DeepSeek模型进行回复。

5. 使用DeepSeek免费额度

DeepSeek新用户提供免费API额度, 可以在DeepSeek控制台查看使用情况:

登录DeepSeek平台
进入Dashboard页面
查看API使用统计和剩余额度

如果免费额度用完, 可以充值付费使用或换其它的服务商，但目前Deepseek是性价比最高的。

配置Telegram频道

Telegram是OpenClaw最常用的消息推送渠道之一。配置Telegram频道需要创建Bot并获取Bot Token。

1. 创建Telegram Bot

在Telegram中搜索并添加BotFather (@BotFather)
发送命令 /newbot 创建新机器人
按提示设置机器人的名称和用户名
创建成功后,BotFather会返回一个Bot Token,格式如 123456789:ABCdefGHIjklMNOpqrsTUVwxyz
保存这个Token,后续配置需要用到

2. 配置OpenClaw

直接用onboard命令配置即可。

获取Telegram用户ID的方法:

在Telegram中搜索并添加userinfobot (@userinfobot)
点击"Start"按钮
机器人会返回你的用户ID

3. 配置Webhook(可选)

如果你有公网域名,可以配置Webhook来接收Telegram消息:

确保域名可以访问到OpenClaw服务
设置Telegram Webhook:

curl -X POST "https://api.telegram.org/bot你的Bot Token/setWebhook" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://你的域名/webhook/telegram",
    "secret_token": "your-secret-key"
  }'

验证Webhook设置:

curl "https://api.telegram.org/bot你的Bot Token/getWebhookInfo"

4. 重启服务

配置完成后,重启OpenClaw服务使配置生效

5. 测试

在Telegram中找到你的Bot,发送消息"hello",如果配置正确,应该能收到AI的回复。

对接钉钉

OpenClaw可以通过插件对接钉钉,实现消息推送到钉钉群聊。这里使用开源插件 soimy/openclaw-channel-dingtalk。

1. 创建钉钉机器人

在钉钉群设置中选择"智能群助手"
点击"添加机器人" -> “自定义”
设置机器人名称,例如"OpenClaw"
设置安全设置,推荐选择"加签"方式
创建成功后,会获得:
- Webhook地址
- 加签密钥(Secret)

保存这些信息,后续配置需要用到。

2. 安装钉钉插件

直接在配置好的TG或openclaw的webui中把插件链接给它，让它自己配置。

3. 测试钉钉推送

重启OpenClaw服务

直接和钉钉机器人对话，或建个群后在钉钉群中发送包含触发关键词的消息,例如"AI你好",OpenClaw应该会响应并返回AI的回复。

在Docker上安装OpenClaw

Docker部署方式适合快速测试和在容器化环境中使用OpenClaw。

1. 准备工作

确保系统已安装Docker和Docker Compose

2. 创建项目目录

mkdir -p ~/openclaw
cd ~/openclaw

3. 创建docker-compose.yml

创建 docker-compose.yml 文件:

cat > docker-compose.yml << EOF
version: '3.8'

services:
  openclaw:
    image: ghcr.io/openclaw/openclaw:2026.4.22-slim
    container_name: openclaw
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ~/openclaw:/home/node/.openclaw
    environment:
      - TZ=Asia/Shanghai
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
EOF

5. 启动OpenClaw

# 拉取镜像并启动服务
docker-compose up -d

# 查看日志
docker-compose logs -f

# 查看服务状态
docker-compose ps

6. 管理命令

# 停止服务
docker-compose stop

# 启动服务
docker-compose start

# 重启服务
docker-compose restart

# 查看日志
docker-compose logs -f

# 进入容器
docker-compose exec openclaw sh

# 更新镜像
docker-compose pull
docker-compose up -d

7. 数据持久化

OpenClaw的数据(包括对话历史、配置等)会保存在 ~/.openclaw 目录中。建议定期备份这个目录:

# 备份数据
tar -czf openclaw-backup-$(date +%Y%m%d).tar.gz data/

# 恢复数据
tar -xazf openclaw-backup-20260210.tar.gz

常见问题

1. 服务无法启动

检查日志查看错误信息:

# 系统安装方式
sudo journalctl -u openclaw -n 50

# Docker方式
docker-compose logs -f

常见原因:

配置文件语法错误
端口被占用
权限不足

2. 消息发送失败

检查:

API Key是否正确
网络连接是否正常
渠道配置是否正确(如Bot Token、Webhook地址等)
是否有防火墙限制

3. Docker容器无法访问外网

检查Docker网络配置:

# 检查Docker网络
docker network inspect bridge

# 重启Docker服务
sudo systemctl restart docker

4. 更新OpenClaw

系统安装方式:

openclaw update

Docker方式:

docker-compose pull
docker-compose up -d

总结

本文介绍了OpenClaw的多种安装和使用方式:

系统安装: 使用一键安装脚本在Debian上安装,适合长期运行的服务器环境
Telegram配置: 创建Bot并配置Webhook,实现Telegram消息推送
DeepSeek API配置: 对接国内优秀的AI模型提供商,支持免费和付费API
钉钉对接: 使用开源插件实现钉钉群聊消息推送
Docker部署: 使用Docker Compose快速部署,适合测试和容器化环境

OpenClaw提供了灵活的消息推送解决方案,可以根据实际需求选择合适的安装方式和配置选项。建议在生产环境中使用系统安装方式,并定期备份数据。

参考资源

OpenClaw官方文档: https://openclaw.ai
Telegram Bot API: https://core.telegram.org/bots/api
钉钉机器人开发: https://open.dingtalk.com/document/robots/custom-robot-access
钉钉插件仓库: https://github.com/soimy/openclaw-channel-dingtalk

推送到[go4pro.org]

在K8s上部署Mastodon

Sun, 04 Jan 2026 21:54:21 +0800

准备工作

因为原来用于跑毛象的服务器（参见旧文《Docker下的Mastodon安装笔记》）到期停机了，正好手里有一个高配的arm免费机可以用，于是就打算把服务迁移过来——顺便试试部署到K8s上。

需要：

一台或多台服务器集群，内存至少4G，推荐8G，最好16G或更多，有外网IP，有一个域名
安装Kubernetes集群（可以使用k3s、minikube或云服务商的K8s服务，本文使用一个kubeadm安装的单节点k8s，见《在单机上用kubeadm安装K8s》）
一个SMTP服务——第三方或本地，这里用了第三方服务
创建必要的存储目录（根据实际节点名称调整路径，这里使用/var/data）
拉取Redis/Postgresql/ES/Mastodon镜像

crictl pull redis:7-alpine
crictl pull postgres:17-alpinie
crictl pull elasticsearch:7.10.1
crictl pull ghcr.io/mastodon/mastodon:v4.5.2
crictl pull ghcr.io/mastodon/mastodon-streaming:v4.5.2

配置存储

1. 创建命名空间

首先创建mastodon命名空间：

kubectl apply -f ns_mastodon.yml

ns_mastodon.yml

apiVersion: v1
kind: Namespace
metadata:
  name: mastodon

2. 配置Local PV/PVC（用于有状态服务）

我们使用local PV/PVC为PostgreSQL、Redis和Elasticsearch提供持久化存储：

Redis存储配置

# 创建Redis数据目录（在目标节点上）
sudo mkdir -p /var/data/redis/data
sudo chown 999:999 /var/data/redis/data

# 应用PV/PVC配置
kubectl apply -f local_redis.yml

local_redis.yml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-redis-data
  labels:
    type: local
spec:
  capacity:
    storage: 10Gi  # 总容量，根据实际需要调整
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-redis-data
  local:
    path: /var/data/redis/data
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - myserver  # 替换为实际节点名称
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: redis-data-pvc
  namespace: mastodon
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi  # 主数据存储大小
  storageClassName: local-redis-data
  selector:
    matchLabels:
      type: local

PostgreSQL存储配置

# 创建PostgreSQL数据目录（在目标节点上）
sudo mkdir -p /var/data/pgdata
sudo mkdir -p /var/data/pgbak
sudo chown 70:70 /var/data/pgdata /var/data/pgbak
sudo chmod 700 /var/data/pgdata

# 应用PV/PVC配置
kubectl apply -f local_posgresql.yml  # 内容参考redis，不过需要配置data和bak两个PV/PVC

Elasticsearch存储配置

# 创建Elasticsearch数据目录（在目标节点上）
sudo mkdir -p /var/data/elasticsearch
sudo chown 1000:1000 /var/data/elasticsearch

# 应用PV/PVC配置
kubectl apply -f local_elasticsearch.yml  # 内容参考redis

3. 配置NFS PV/PVC（用于Mastodon Public文件夹）

Mastodon需要共享存储来存储用户上传的媒体文件，因为需要同时给两个服务（web和streaming）使用，所以使用NFS PV/PVC：

# 创建NFS共享目录
sudo mkdir -p /var/data/mastodon
sudo chown 991:991 /var/data/mastodon

# 配置NFS服务器（如果尚未配置）
# 安装NFS服务器
sudo apt-get install nfs-kernel-server

# 配置NFS导出
echo "/var/data/mastodon *(rw,sync,no_subtree_check,no_root_squash,all_squash,anonuid=991,anongid=991)" | sudo tee -a /etc/exports
sudo exportfs -a  # 应用配置
sudo systemctl restart nfs-kernel-server
sudo exportfs -v  # 查看应用结果

# 应用NFS配置
kubectl apply -f nfs_mastodon.yml

nsf_mastodon.yml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-mastodon-data-web
  labels:
    type: nfs
spec:
  capacity:
    storage: 150Gi  # 总容量，根据实际需要调整
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs-mastodon-data-web
  nfs:
    server: 10.244.0.1  # flannel的IP
    path: /var/data/mastodon
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mastodon-data-web-pvc
  namespace: mastodon
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 150Gi  # 主数据存储大小
  storageClassName: nfs-mastodon-data-web
  selector:
    matchLabels:
      type: nfs
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-mastodon-data-sidekiq
  labels:
    type: nfs
spec:
  capacity:
    storage: 150Gi  # 总容量，根据实际需要调整
  volumeMode: Filesystem
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs-mastodon-data-sidekiq
  nfs:
    server: 10.244.0.1  # 连同一个NFS
    path: /var/data/mastodon
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mastodon-data-sidekiq-pvc
  namespace: mastodon
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 150Gi  # 主数据存储大小
  storageClassName: nfs-mastodon-data-sidekiq
  selector:
    matchLabels:
      type: nfs

部署有状态服务（Stateful Headless Services）

1. 部署Redis

创建Redis的StatefulSet配置：

kubectl apply -f svc_redis.yml

svc_redis.yml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
  namespace: mastodon
spec:
  serviceName: redis-headless  # 需要一个 Headless Service 管理网络标识
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:7-alpine
        ports:
        - containerPort: 6379
        volumeMounts:
        - name: redis-data
          mountPath: /data
        livenessProbe:
          exec:
            command: ["redis-cli", "ping"]
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          exec:
            command: ["redis-cli", "ping"]
          initialDelaySeconds: 5
          periodSeconds: 10
      volumes:
      - name: redis-data
        persistentVolumeClaim:
          claimName: redis-data-pvc  # 直接使用现有 PVC
  volumeClaimTemplates: []
---
apiVersion: v1
kind: Service
metadata:
  name: redis-headless
  namespace: mastodon
spec:
  clusterIP: None  # Headless Service，直接解析到 Pod IP
  selector:
    app: redis
  ports:
  - port: 6379
    name: redis

2. 部署PostgreSQL

PostgreSQL使用StatefulSet和Headless Service：

kubectl apply -f svc_postgresql.yml  # 内容参考svc_redis.yml，不过要mount两个卷

3. 部署Elasticsearch

创建Elasticsearch的StatefulSet配置：

kubectl apply -f svc_elasticsearch.yml  # 内容参考svc_redis.yml

4. 验证部署

kubectl get statefulsets -n mastodon
kubectl get pods -n mastodon -l app=postgresql
kubectl get services -n mastodon | grep postgresql

配置Mastodon

1. 准备环境配置文件

编辑 env.production 文件，配置以下关键参数：

# Redis配置
REDIS_HOST=redis-headless.mastodon.svc.cluster.local
REDIS_PORT=6379

# 数据库配置
DB_HOST=postgresql-headless.mastodon.svc.cluster.local
DB_PORT=5432
DB_NAME=mastodon
DB_USER=mastodon
DB_PASS=你的数据库密码

# Elasticsearch配置
ES_ENABLED=true
ES_HOST=es-headless.mastodon.svc.cluster.local
ES_PORT=9200

# 域名配置
LOCAL_DOMAIN=你的域名

2. 创建Secret配置

将环境配置创建为Secret：

kubectl create secret generic mastodon-env --from-env-file=env.production -n mastodon

3. 部署Mastodon服务

注意：除非是全新安装的实例，否则此操作需要在数据库恢复后进行。

创建Mastodon的Deployment配置：

kubectl apply -f svc_mastodon.yml  # 类似svc_redis.yml，不过里面有三个服务：web,streaming,sidekiq

其中mastodon的web和streaming是以NodePort方式输出服务。

恢复数据库

1. 全库备份恢复方式

使用pg_dumpall备份全库再恢复到k8s里。

# 从源docker环境备份整个库
docker exec postgresql pg_dumpall -U postgres | gzip > pgoldbak.sql.gz
# 把备份传输到k8s环境
# 恢复数据
gunzip -c pgoldbak.sql.gz | kubectl exec postgresql -i -n mastodon --command -- psql -U postgres

2. 基于WAL的增量备份恢复方式

备份恢复方式参考《PostgreSQL的连续备份配置》

3. 启动实例

恢复数据库确认无误后即可启动毛象实例。

启动服务

所有服务启动后检查状态：

kubectl get all -n mastodon

如果所有Pod都处于Running状态，说明部署成功。如果有问题，则需要查看日志检查原因。

kubectl logs -f <podname> -nmastodon

配置Nginx反向代理

创建Nginx配置，将流量代理到Mastodon服务：

cat > nginx/mastodon.conf << EOF
upstream backend {
    server <NODE_IP>:3xxxx;  # 替换为节点IP和mastodon-web的NodePort
}

upstream streaming {
    server <NODE_IP>:3yyyy;  # 替换为节点IP和mastodon-streaming的NodePort
}

server {
    listen 80;
    server_name 你的域名;
    return 301 https://\$server_name\$request_uri;
}

server {
    listen 443 ssl http2;
    server_name 你的域名;

    ssl_certificate /etc/ssl/你的域名/fullchain.pem;
    ssl_certificate_key /etc/ssl/你的域名/privkey.pem;

    root /var/data/mastodon/public;
    
    location / {
        try_files \$uri @proxy;
    }

    location @proxy {
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto \$scheme;
        proxy_set_header Proxy "";
        proxy_pass_header Server;

        proxy_pass http://backend;
        proxy_buffering off;
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header Upgrade \$http_upgrade;
        proxy_set_header Connection "upgrade";

        tcp_nodelay on;
    }

    location /api/v1/streaming/ {
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto \$scheme;
        proxy_set_header Proxy "";

        proxy_pass http://streaming;
        proxy_buffering off;
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header Upgrade \$http_upgrade;
        proxy_set_header Connection "upgrade";

        tcp_nodelay on;
    }
}
EOF

日常运维

1. 监控服务状态

# 查看所有资源状态
kubectl get all -n mastodon

# 查看Pod日志
kubectl logs -f deployment/mastodon-web -n mastodon
kubectl logs -f deployment/mastodon-streaming -n mastodon
kubectl logs -f deployment/mastodon-sidekiq -n mastodon

# 查看有状态服务日志
kubectl logs -f statefulset/postgresql -n mastodon
kubectl logs -f statefulset/redis -n mastodon
kubectl logs -f statefulset/elasticsearch -n mastodon

2. 定期清理

由于联邦宇宙中的内容会不断增加，需要定期清理过期数据，具体实现与之前docker方式部署一样，只是把docker命令改成相应的kubectl命令。

可以将这些清理任务添加到crontab中定期执行。

3. 备份与恢复

也可以参考前文实现，或者参考pgsql的wal备份那篇用备份wal的方式实现连续备份。

4. 升级Mastodon版本

升级Mastodon需要按顺序进行：

备份数据库
更新镜像版本
重新部署服务

# 更新镜像版本
sed -i 's|ghcr.io/mastodon/mastodon:v4.5.2|ghcr.io/mastodon/mastodon:新版本|g' svc_mastodon.yml
sed -i 's|ghcr.io/mastodon/mastodon-streaming:v4.5.2|ghcr.io/mastodon/mastodon-streaming:新版本|g' svc_mastodon.yml

# 重新部署
kubectl apply -f svc_mastodon.yml

K8s下的rollout升级：

# 不涉及数据库变更的小版本升级可以用rollout方式平稳升级：
kubectl set image deployment/mastodon-streaming streaming=ghcr.io/mastodon/mastodon-streaming:v4.5.4 -nmastodon
kubectl set image deployment/mastodon-sidekiq sidekiq=ghcr.io/mastodon/mastodon:v4.5.4 -nmastodon
kubectl set image deployment/mastodon-web mastodon-web=ghcr.io/mastodon/mastodon:v4.5.4 -nmastodon

kubectl rollout status deployment/mastodon-streaming -nmastodon
kubectl rollout status deployment/mastodon-sidekiq -nmastodon
kubectl rollout status deployment/mastodon-web -nmastodon

升级完成。

故障排除

1. Pod无法启动

检查Pod状态和日志：

kubectl describe pod <pod-name> -n mastodon
kubectl logs <pod-name> -n mastodon

常见问题：

存储卷挂载失败：检查PV/PVC状态 kubectl get pv,pvc -n mastodon
资源配置不足：检查资源限制 kubectl describe pod <pod-name> -n mastodon | grep -A 5 Resources
镜像拉取失败：检查镜像名称和标签

2. 服务无法访问

检查服务状态：

kubectl get services -n mastodon
kubectl describe service <service-name> -n mastodon

确保NodePort在正确范围内（30000-32767）。

3. 数据库连接问题

检查数据库服务：

# 测试数据库连接
kubectl run test-db-connection --rm -i --restart=Never \
  --image=postgres:17-alpine --namespace=mastodon -- \
  psql -h postgresql-headless.mastodon.svc.cluster.local -U postgres -c "\l"

4. 存储问题

检查存储状态：

kubectl get pv,pvc -n mastodon
kubectl describe pvc <pvc-name> -n mastodon

确保本地目录存在且有正确权限。

总结

本指南介绍了如何使用Kubernetes部署Mastodon实例，包括：

存储配置：使用local PV/PVC为有状态服务（PostgreSQL、Redis、Elasticsearch）提供持久化存储
网络配置：使用NFS PV/PVC为Mastodon public文件夹提供共享存储
服务部署：使用StatefulSet和Headless Service部署有状态服务，使用Deployment部署无状态服务
运维管理：包括监控、清理、备份、升级等日常运维操作

相比docker-compose部署方式，Kubernetes部署提供了更好的可扩展性、高可用性和运维便利性。可以根据实际需求调整资源配置和副本数量。

注意事项

安全性：生产环境需要配置更严格的安全策略，如Network Policies、Pod Security Policies等
性能：根据实际负载调整资源限制和副本数量
监控：建议配置Prometheus和Grafana进行监控
备份：定期备份数据库和重要数据
更新：关注Mastodon和安全更新，及时升级

如有问题，请参考Mastodon官方文档或Kubernetes官方文档。

推送到[go4pro.org]

将supervisor迁移到systemd

Sat, 20 Dec 2025 21:58:45 +0800

历史问题

在前systemd时代，要配置一个启动运行的服务还是比较麻烦的，所以才有了supervisor这种服务，但是现在systemd已经很成熟了，不再需要多此一举：

systemd启动supervisord，supervisord再来启动自定义服务

是时候把supervisor的服务迁移到systemd下了。

转换配置文件

首先是把/etc/supervisor/conf.d/下面的服务配置文件改成systemd格式的，然后放到/etc/systemd/system/下。

转换对照表如下：

Supervisor 指令	systemd 指令	说明
command	ExecStart	运行程序的完整路径和参数
directory	WorkingDirectory	程序运行的起始目录
user	User	运行该服务的用户
environment	Environment	环境变量设置
autostart	WantedBy=multi-user.target	是否随系统启动
autorestart	Restart=always	进程退出后是否自动重启
stdout_logfile	StandardOutput	标准输出（通常交给 journald）
stderr_logfile	StandardError	标准错误输出

一个典型的systemd服务单元配置如下：

[Unit]
Description=My Python Application
After=network.target

[Service]
# 基础配置
User=www-data
Group=www-data
WorkingDirectory=/var/www

# 环境变量 (注意语法：空格分隔或多次声明)
Environment=NODE_ENV=production
Environment=PORT=8080

# 启动命令 (必须使用绝对路径)
ExecStart=/usr/bin/python3 /var/www/app.py

# 重启策略
Restart=always
# 启动失败后的等待时间（可选）
RestartSec=5

# 日志处理：默认会发送到 journald
StandardOutput=append:/var/log/my-app.out.log
StandardError=inherit

[Install]
# 允许随系统启动
WantedBy=multi-user.target

管理systemd服务

常用的命令如下：

# 新增或修改配置文件以后需要重新加载，类似 supervisorctl reread && supervisorctl update，或者更粗暴的supervisorctl reload
systemctl daemon-reload
# 查看服务状态
systemctl status [yourservice]
# 设置服务开机自启动
systemctl enable [yourservice]
# 加上--now选项可以在设置后立即启动服务，同理用disable命令可以禁用开机自启动
# 手工启动服务
systemctl start [yourservice]

推送到[go4pro.org]

Linuxmint中蓝牙配对问题的处理

Sat, 08 Nov 2025 17:35:07 +0800

起因

最近常用的这个Linuxmint系统忽然无法添加蓝牙设备了，表现为可以搜索到要添加的设备，但是点击添加后，显示正在连接，很长时间连不上，然后就报错了。有时也可以连接上，但是无法使用，一会之后又断开了。

问AI半天也没有解决方案，什么重启蓝牙服务，重装蓝牙管理器之类的方法都试过了，没一个管用的。甚至还试了改polkit权限配置、重新加载蓝牙内核模块之类的方法，也没用。

解决

自己试了半天后发现问题出在无法弹出配对确认框上，但是这个问题始终没有找到解决方案，最后只能通过手工配对的方式来解决：

# 进入命令行状态：
bluetoothctl
# 在交互界面操作：
power on
agent on
scan on
# 现在开始扫描周围的蓝牙设备，记录一下要添加的设备MAC
# 配对设备
pair <设备MAC>
# 信任设备（就是弹框需要做的操作）
trust <设备MAC>
# 连接设备
connect <设备MAC>

这样配对好以后就可以正常使用蓝牙设备了。

推送到[go4pro.org]

Ansible贴士二则

Sun, 12 Oct 2025 15:22:55 +0800

避免主机SSH指纹确认

通常在第一次用SSH连接一台远程主机的时候，都会弹出一个SSH指纹警告，需要人工确认后，把这个指纹加到本地.ssh/knwon_hosts文件中。以后要是同一远程主机的指纹变化了（比如被冒充），就会导致SSH报错后断开连接，除非你能确认这种变化，那就需要从known_hosts里把原来的指纹删除：

ssh-keygen -R remote_host:port

然后再次连接并确认记录新指纹。

手工单次连接时顺手确认一下没什么问题，但是用Ansible连接实际上也是走ssh，也要验证指纹，所以也会有这个交互过程。

但这就麻烦了，因为通常用Ansible跑playbook时都是需要处理一堆主机的，每个都这样人工确认就太麻烦了，所以更好的办法是先批量更新一下known_hosts：

# 主机地址列表
HOSTS=(xxx yyy zzz)

for h in "${HOSTS[@]}"
do
    ssh-keyscan -p 22 $h >> ~/.ssh/knwon_hosts
done

使用指定的key连接

通常用ssh连接时，可以通过-i参数指定key文件，比如：

ssh -i /path_to/your_key_file user@host

Ansible里也可以指定，使用ansible_ssh_private_key_file变量：

ansible_ssh_private_key_file: /path_to/your_key_file

外一则

之前在Ansible中创建用户用的生成密码命令：

python3 -c "import crypt; print(crypt.crypt('{{ plain_password }}'))"

现在会报一个警告：

DeprecationWarning: 'crypt' is deprecated and slated for removal in Python 3.13

从Python3.13开始要移除crypt模块了，所以需要换个方式。

一个方式是使用passlib模块：

python3 -c "from passlib.hash import sha512_crypt; print(sha512_crypt.hash('your_password'))"

不过更好的方法是使用Ansible内置的过滤器：

- name: 创建用户
  hosts: all
  vars:
    plain_password: "your_password"
  
  tasks:
    - name: 创建用户（使用过滤器生成哈希）
      user:
        name: youruser
        password: "{{ plain_password | password_hash('sha512') }}"
        state: present
      no_log: true

推送到[go4pro.org]

基于wstunnel的反向隧道配置

Sat, 06 Sep 2025 15:19:00 +0800

需求

因为家里一条宽带换成移动的，没有外网IP了，所以从外面接入不太方便，IPv6虽然也是个方案，但是内网那台arm小机器是很老的Debian7，没有驱动也升级不了系统，还是搞个隧道简单点。

之前《使用docker和wstun实现隧道和反向隧道》，但是这个用Node.js实现的太笨重了，而且debian7上也装不了docker。还好现在有新方案，就是这个用Rust实现的wstunnel。一个可执行文件轻松跑起，还支持32位arm linux。

简单起见这里不再说正向隧道的配置了，参考前文，换成wstunnel即可。下面只说反向隧道的。

服务端

直接运行是最简单的：

wstunnel server ws://[::]:8080

但是这样有个安全风险就是只要能连接到这个websocket服务端就可以任意映射端口，等于绕过了防火墙的检查。

虽然官方建议是可以加上https和随机的path-prefix加以防护，但我觉得还是直接包进docker里更保险一点。

用Rust的好处之一就是这是独立可执行文件，没有依赖，直接用一个最小系统镜像（如alpine:3.22）就能运行：

docker run -d --name wstunnel -v $HOME/opt:/root/opt -p 127.0.0.1:8080:8080 -p 0.0.0.0:8022:8022 alpine:3.22 /root/opt/wstunnel server ws://[::]:8080

这个命令的功能就是用alpine:3.22的镜像来运行wstunnel（放在$HOME/opt下），把websocket端口8080映射到本地，把反向隧道的端口8022映射到外网。这样即使有其它的客户端想到映射别的端口，或者映射服务器的端口都无法实现，因为都是在docker容器里面。

当然为了保险起见，可以继续叠加官方的安全手段。

客户端

因为无法运行docker，就只能直接运行了：

wstunnel client -R 'tcp://[::]:8022:127.0.0.1:22' ws://server:8080

为了保持运行，我实际上是用supervisor加持了一下。

远程的地址实际上也不是这个，而是用https代理过的。

服务端https代理配置

也是使用Nginx的反向代理，如前文：

# 在http段加上全局配置
map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}
# 在server段加上代理配置
    location / {
        proxy_pass http://127.0.0.1:8080;
        
        # 启用WebSocket支持的关键配置
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        # 保持连接和代理头信息
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # 设置较长的超时时间以保持持久连接
        proxy_read_timeout 86400;
        proxy_send_timeout 86400;
        keepalive_timeout 86400;
    }

这样配置以后，只要服务端和客户端保持运行，就可以通过服务端的8022端口连接到客户机的22。

推送到[go4pro.org]

在CentOS8.5上使用docker-compose

Sat, 02 Aug 2025 15:13:17 +0800

起因

说过很多次，我非常不喜欢CentOS，想用RedHat系就掏钱去用RHEL，不然就老老实实Debian之类。然而却不得不经常要面对别人装的CentOS。

这回就是这样，需要在一个别人装的CentOS8.5上装docker-compose。

安装docker

CentOS早就停止支持这事大家都知道了吧，当然旧版还是有archive源可以用的，我就用了一个阿里云的archive源来安装。

先备份原来的源配置，然后换成阿里，再安装：

cp /etc/yum.repos.d/epel.repo /etc/yum.repos.d/epel.repo.backup
cp /etc/yum.repos.d/epel-modular.repo /etc/yum.repos.d/epel-modular.repo.backup
# 下载并替换epel配置
wget -O /etc/yum.repos.d/epel.repo https://mirrors.aliyun.com/repo/epel-archive-8.repo
# 然后更新一下
yum update
# 因为RH系不提供docker，而是使用podman，所以只能安装兼容的podman-docker
yum install podman-docker

安装docker-compose

虽然这事已经是陈年往事了，但还是说明一下：因为docker是带有一个docker服务的，这点被嫌弃很多年，所以后来出了一些不需要服务的容器方案，比如containerd和podman。K8s也已经完全抛弃了docker。

但用这些方案带来的问题就是有些docker的功能不支持，比如docker-compose。

为了提供类似的功能，也有一些部分解决方案，比如现在我们要用的。

首先是配置podman.socket以提供一个docker服务兼容接口：

# 启用podman.socket服务
systemctl enable --now  podman.socket
systemctl status podman.socket
# 配置环境变量供docker-compose使用
export DOCKER_HOST=unix:///run/podman/podman.sock
# 也可以配置到.bashrc里

然后安装一下docker-compose：

# 先升级一下可能需要的依赖
pip3 install --user -U pip
pip3 install --user -U wheel
pip3 install --user -U setuptools
pip3 install --user -U setuptools_rust
# 安装docker-compose
pip3 install --user docker-compose

现在就可以正常使用docker-compose了：

~/.local/bin/docker-compose up -d

但是有些功能还是不能用的，比如docker-compose build，这种就只能先用podman把镜像先build好再用docker-compose了。

podman build -t your_image .

至少是能用了。

推送到[go4pro.org]

用uv代替pip和venv

Sat, 26 Jul 2025 11:17:09 +0800

为什么要换

python的环境管理用过很多了，从最早的virtualenv到后来封装后的virtualenvwraper再到现在用的自带的venv，确实是越来越好用的。不过最近这个用rust写的uv似乎比较红，群里的MK和95也推荐，所以我也来试试。

安装

MK说只要pip install uv就可以了，但是在我的mint上似乎没这么简单。

首先是现在不允许直接安装系统python包了，怕破坏依赖关系，虽然可以加参数强制安装，但毕竟有风险。这种情况我通常是去apt里找一个类似：python3-uv这样的包来装，但不幸的是mint里还没有。

只好退而用另一个替代方案：

sudo apt install pipx
pipx install uv  # 官方源如果太慢，可以用-i参数使用国内镜像源
# 安装路径在$HOME/.local/bin，记得加到PATH里

使用

使用方法类似venv，只是需要前面加上uv命令。

uv venv # 在当前路径下创建.venv的虚拟环境，如果不想用.venv，可以在后面指定名字
. .venv/bin/activate # 切换到虚拟环境
uv pip install -r requirements.txt # 也可以用-i使用国内镜像源，不过uv不支持在requirements.txt里用--index指定源

安装速度真的是比pip高不知道哪里去……

需要注意的是，uv pip并不会使用默认的~/.pip/pip.conf里的配置，而是有自己的配置文件：~/.config/uv/uv.toml，所以如果想要指定默认镜像，还得加到这个配置文件里，比如：

# ~/.config/uv/uv.toml

index-url = "https://mirrors.aliyun.com/pypi/simple/"

虚拟环境

需要注意的是，在pip中，可以在不切换到虚拟环境的情况，直接使用类似.venv/bin/pip命令来直接管理虚拟环境里的包。这个功能在docker构建的时候特别好用。但是uv不行，不论是否在虚拟环境里，运行的uv命令都是在~/.local/bin下的，所以如果想在不切换到虚拟环境的情况下进行虚拟环境里的包管理则需要通过两种方式：

一种是在虚拟环境里安装一个uv，然后使用这个uv。另一种是指定使用虚拟环境里的python。

安装uv法：

. .venv/bin/activate # 切换到虚拟环境
uv pip install uv  # 在虚拟环境里安装uv
deactivate # 退出虚拟环境
.venv/bin/uv pip install -r requirements.txt  # 在虚拟环境里安装依赖

指定python法：

~/.local/bin/uv pip install -p .venv/bin/python -r requirements.txt  # 在.venv虚拟环境里安装依赖

个人推荐后者，因为比较简洁。

其实根本问题就是uv创建虚拟环境的时候没有默认在环境里装一个uv，但pip的虚拟环境里默认是有pip的。

推送到[go4pro.org]

DBeaver的数据库连接保持配置

Sat, 21 Jun 2025 11:09:33 +0800

问题

因为需要管理mysql和postgresql，所以我通常使用DBeaver（CE版）来管理，但是它有个问题就是一会不操作，数据库连接就会断开并且操作卡死，需要退出应用再重新运行才行，相当麻烦，所以前几年我在Mac下连mysql还是经常用Sequel Pro（后来的Ace）。

这几年改用Linux以后，就完全用DBeaver了，虽然中间也研究过一些配置，但也并不总是管用，想想还是把这些设置都记录一下，慢慢总结看看到底哪些方法是管用的。

全局配置

首先打开DBeaver的系统设置，找到全局设置（在菜单的“窗口”-“首选项”），将“连接”下的“错误和超时”设置中的“执行错误”-“自动重连次数”改大一点，比如3次，增加连接成功率。

数据库连接配置

然后在具体的数据库连接的“编辑连接”中的“连接设置”-“驱动属性”里修改以下几项（根据数据库不同可能有所不同）：

autoReconnect=True
connectionTimeout=3600
tcpKeepAlive=True

SSH隧道连接配置

如果通过SSH隧道连接，还需要再修改SSH里的“高级”：

修改“长连接时间间隔”，我一般用30秒，因为这里单位是毫秒，所以填：30000。

这项用于每30秒与SSH服务端通信一下，保持SSH连接。

经过以上几荐修改后，数据库连接可以较为稳定，正常情况下都不会断连，即使因为网络中断而断连后，重连也很正常，不像之前会重连卡死或反复重连失败。

推送到[go4pro.org]

用Alembic进行数据库版本管理

Sun, 25 May 2025 10:41:02 +0800

序

用SQLAlchemy进行数据库开发是很方便，特别是它有强大的ORM，只要在model里把数据库模型定义好，直接初始化一下就行了。

但是实际的开发不可能一开始就把数据库定义得这么完善，另外，也有时会碰到先有数据库再进行开发的情况，这时就比较麻烦了。

所以需要有工具支持。

Alembic就是一个配合SQLAlchemy的数据库管理工具。

在介绍Alembic之前，先来看看已经有数据库时要怎么办。

已有数据库

如果你之前已经用过SQLAlchemy，更常见的情况是实际的数据库经过一段时间的修改已经与早期定义的models不一致。不论是之前已有数据库，还没创建models，还是已有models，但与数据库不一致，都可以如下处理。

这就需要另外一个工具：sqlacodegen。安装的话就是一句PIP的事情：

pip install sqlacodegen

然后用命令（以Mysql为例，pg的话就用psycopg2）：

sqlacodegen mysql+pymysql://user:pass@localhost:3306/dbname --outfile db/models.py

即可从数据库生成一个SQLAlchemy的models定义文件。有了这个保持一致的models才好用alembic来管理。

初始化

安装就不说了，也是一句PIP的事情。

然后在项目路径下执行：

alembic init alembic

会创建几个文件和目录：alembic.ini，alembic目录及其下面的env.py, README, script.py.mako和versions目录。

最简单的用法就是在alembic.ini里找到sqlalchemy.url参数，改为当前开发环境的数据库连接。然后修改alembic/env.py：

from db.models import Base  # 从你的sqlalchemy的models定义中导入Base

# ...

target_metadata = Base.metadata  # 把原来默认的None改为你的Base.metadata，以便alembic可以找到你的数据库模型定义

然后执行：

alembic revision --autogenerate -m "init"

即可以versions目录下生成一个版本文件。

如果数据库不存在，则这个版本可以作为初始化的建库基础。如果数据库已存在，那models一定要与现在的数据库保持一致，最好是用sqlacodegen从数据库重新生成一个models。

然后运行：

alembic upgrade head

如果数据库是新的空库，这个操作就会根据models的定义创建一个数据库结构。如果数据库已存在并且与models定义一致，即可将开发环境的数据库的alembic版本标记为当前版本，以便后续变更。

之后部署到正式环境，只需要配置好正式环境的数据库链接，然后运行alembic upgrade head，即可创建一个和开发环境一致的数据库。

版本升级

随着开发工作的进行，数据库肯定也会变更，这个时候要注意，不要直接在开发数据库上变更，所有的变更都要在sqlalchemy的models上进行。在更新了models以后，执行：

alembic revision --autogenerate -m "new feature"

生成一个new feature的alembic新版本记录。同样在生成以后alembic upgrade head更新一下开发环境的数据库版本。这样数据库就与models一致了，可以继续进行开发。

部署到正式环境后，同样执行一下alembic upgrade head，即可将正式环境数据库更新到和开发环境一致，这时再部署代码运行就不会有数据库不一致的问题了。

关于配置

修改alembic.ini里的数据库链接固然方便，但是不便于与生产环境同步，所以最好还是动态读取实际的配置。

假设配置信息放在一个单独的配置文件config.py里，生产环境和开发环境用的配置文件是不一样的，代码里通过一个Config类去读取，类似这样：

class Config:
    config: dict = load_config()  # 从配置文件里读取配置
    DB_URL: str = config.get("DB_URL")  # 读取数据库配置
    
settings = Config()

那么我们现在就可以来修改alembic的配置，让它去读取实际的配置，而不是写死在alembbic.ini里，这样不论是在开发环境还是在生产环境运行alembic，使用的都是正确的数据库配置。

首先修改alembic.ini，把sqlalchemy.url一项注释掉，然后修改alembic/env.py，让它改为读取项目配置，而不是alembic.ini：

# 导入配置
from config import settings

# ...

# 修改run_migrations_offline函数
def run_migrations_offline() -> None:
    # url = config.get_main_option("sqlalchemy.url")  # 注释掉原来读取alembic.ini的语句
    url = settings.DB_URI  # 改为读取项目配置
    
    # ...
    
# ...

# 修改run_migrations_online函数
def run_migrations_online() -> None:
    # 读取项目配置并设置到alembic的sqlalchemy配置里
    url = settings.DB_URI
    config.set_main_option("sqlalchemy.url", url)
    
    connectable = engine_from_config(
        config.get_section(config.config_ini_section, {}),
        prefix="sqlalchemy.",
        poolclass=pool.NullPool,
    )

    # ...
    
#...

这样就可以方便地在开发环境和生产环境之间同步了。

记得每次开发环境有修改过数据库模型，就创建一个alembic版本。

——注意，只能在models.py里修改，不得直接修改数据库

提交代码的时候把alembic版本一起提交上去，在正式环境上部署时同样要把变更的alembic版本更新下来，然后运行alembic upgrade head同步生产环境的数据库结构，这样就能保持一致了。

推送到[go4pro.org]