搭建最新的VLESS Vision和VLESS Reality防止VPS端口封禁

一、介绍

为了应对 TLS in TLS 和指纹识别等阻断或封禁的风险,Xray-core 团队推出了 VLESS Vision 和 VLESS Reality 两种新颖的技术方案。它们能够有效地隐藏保护流量的特征,提高安全性稳定性。如果您想了解更多详细信息,请点击 Vision 和 Reality 的查看。

协议组合 解决 TLS in TLS 解决指纹问题 自带多路复用 是否支持CDN
VLESS-Vision-TLS
VLESS-Vision-uTLS-REALITY
VLESS-gRPC-uTLS-REALITY

二、环境

三、搭建步骤

1.ssh登录服务器(略)

2.下载脚本

wget -P /root -N --no-check-certificate "https://raw.githubusercontent.com/mack-a/v2ray-agent/master/install.sh" && chmod 700 /root/install.sh && /root/install.sh
Bash

3.安装

  • 两种安装方式,第一种需要自己购买域名第二种无需购买域名
  • 如果没有域名,可以跳过第一种安装方式。

1.第一种安装方式(需要域名)

  • 建议选择 2任意组合安装->选择0,7 ,这样的安装会同时安装 Vision_TLSReality+TCP+uTLS+VisionReality+gRPC+uTLS
  • 路径:vasma->2->1->0,7

第一步,输入域名

custom_reality_domain.png

第二步,端口默认443即可,也可以自定义端口安装

custom_reality_install02.png

第三步,注意事项。

当配置VLESS+Reality 需要注意一下,这里的端口可以自定义,如果上方使用了自定义端口这里则可以输入 443 。

剩下的一直回车后会自动展示账号,到这里有域名的情况就搭建完成了。

custom_reality_install03.png

2.第二种安装方式(无需域名)【推荐安装】

可参考的域名


# Apple
gateway.icloud.com
itunes.apple.com
swdist.apple.com
swcdn.apple.com
updates.cdn-apple.com
mensura.cdn-apple.com
osxapps.itunes.apple.com
aod.itunes.apple.com,

# mozilla
download-installer.cdn.mozilla.net
addons.mozilla.org

# CDN
s0.awsstatic.com
d1.awsstatic.com
cdn-dynmedia-1.microsoft.com

# amazon
images-na.ssl-images-amazon.com
m.media-amazon.com

# google
dl.google.com
www.google-analytics.com

# 其他
player.live-video.net
one-piece.com
lol.secure.dyn.riotcdn.net
www.lovelive-anime.jp
www.swift.com
academy.nvidia.com
www.cisco.com
www.samsung.com
www.amd.com
software.download.prss.microsoft.com
Bash

四、客户端配置

手动配置示例

  • VLESS Reality gRPC uTLS
 - name: reality-grpc
   server: vpsIP
   type: vless
   port: 端口
   uuid: id
   network: grpc
   servername: 允许客户端访问的域名,对应的是服务端 serverNames
   flow: ""
   udp: true
   tls: true
   reality-opts:
     public-key: 服务端的publicKey
   client-fingerprint: chrome
   grpc-opts:
     grpc-service-name: grpc
YAML
  • VLESS Reality TCP Vision uTLS
- name: reality-tcp
  server: vpsIP
  type: vless
  port: 端口
  uuid: ip
  network: tcp
  servername: 允许客户端访问的域名,对应的是服务端 serverNames
  flow: xtls-rprx-vision
  udp: true
  tls: true
  reality-opts:
    public-key: publicKey
  client-fingerprint: chrome
YAML
  • VLESS TCP TLS Vision uTLS
- name: Vision-tcp
  server: IP
  type: vless
  port: port
  uuid: uuid
  network: tcp
  serviceName: 域名
  flow: xtls-rprx-vision
  udp: true
  tls: true
YAML

3.iOS

1.V2BOX

  • 支持RealityVision
  • vasma->7.账号管理->2.查看订阅 拉取即可
  • 客户端配置->Configs->右上角+号->Add Subscription

2.FoXray

  • 支持RealityVision
  • vasma->7.账号管理->2.查看订阅 拉取即可
  • 客户端配置->订阅列表->右上角+号

3.Shadowrocket

  • vasma->7.账号管理->2.查看订阅 拉取默认订阅即可

4.sing-box

  • vasma->7.账号管理->2.查看订阅 拉取sing-box订阅即可
  • Profiles->New Profiles->Type(Remote)->复制sing-box订阅链接到URL

ios_sing-box.jpg

4.Windows

1.v2rayN[需下载最新]

1.reality-tcp

reality_tcp.png

2.reality-grpc

reality_grpc.png

五、注意事项

1.Vision被封答疑【以下内容来源

首先,如果你特别不想被封,请先选择一个干净的 IP,并按照 配置正确 去搭建、使用 XTLS Vision。

但是,即使你这样做了,也无法保证 100% 不被封。自去年底始,很多人的未知流量秒封 IP,TLS in TLS 流量隔天封端口。XTLS Vision 不是未知流量,且完整处理了 TLS in TLS 特征,目前看来效果显著。但这并不意味着,用 XTLS Vision 可以 100% 不被封,认识到这一点是非常、非常重要的,不要自己偶然被封就大惊小怪

因为除了协议本身,还有很多角度能封你。以 IP 为例,你无法保证 IP 真的干净,无法避免被邻居波及,无法避免整个 IP 段被重点拉清单。也有可能某些地区的 GFW 有独特的标准,比如某个 IP 只有寥寥数人访问连却能跑那么多流量,封。如果你的 XTLS Vision 被封了,但没有出现去年底 TLS 那样的大规模被封报告,我真心建议你换端口、换 IP、换服务商依次试一遍

排查

  • 打开[ping.pe]
  • 输入 IP 检测ping可用
  • 输入 IP:Port 检查端口是否可用
  • 主要是看最后几个是否为绿色

2.Reality不支持CDN

3.Reality工作原理

一些GitHub issues的零碎信息,完整版本可以等xray-core更新文档

#1734
#1701
#1697
#1697
#1588

4.Xray-core内存问题解答【以下内容来源

Xray 占几百兆内存,并不代表这是最低要求,而是正是因为你有空闲的内存,Xray 才会拿来当缓存、备用,因为不用白不用。

仅此而已,内存完全够用的情况下,却非要追求这个数据的好看,想捂着不让 Xray 用,有什么意义呢?VPS 商家给你退钱?

对于 Xray 这样的代理类软件,内存占用大头在于对被代理数据的缓存,能用的内存多就能多缓存一些数据,麻烦搞清楚状况。

换句话说,内存占用大头取决于你要的缓存数据能力,每个代理软件的默认策略不一样,你调低缓存自然就可以实现数据的好看

5.影响Reality使用体验的几个因素【以下内容来源

目标网站/域名的选择会极大程度地影响 REALITY 代理的延迟、速度、稳定性等:

  1. 至少目前,REALITY 每次都要去拿握手包,需要注意目标网站近不近、稳不稳定(请求多了就把你半拉黑也是一种不稳定)。
  2. 运营商层面可能会给某些域名更高的流量优先级,拥堵时优先保证它们的流量通过。
  3. GFW 层面至少有黑名单(google)和白名单(microsoft),可能还有其它名单,比如偶尔干扰/限速名单(github?)

如果出现今天不可用但是昨天可用的情况,可能出现的原因:

也可能是你们天天逮着 microsoft、apple 之类的偷,GFW 开始测试了,有人说伊朗那边就有运营商在“内测” yahoo 的 IP 白名单。

REALITY 以后会出个缓存模式,提前采集目标网站的特征,就不用每次都去拿了,这也是相对于 ShadowTLS 之类的优势之一。

还有就是 REALITY 隐藏玩法的任意 SNI、无 SNI,对 REALITY 来说,只要服务端 serverNames 写了,客户端 serverName 就能填。
我需要说明一下不是只有 1.1.1.1 和 8.8.8.8,而是绝大多数网站都有“默认证书”。不过不希望这个玩法泛滥,因为特征明显。

6.v1.8.1 增强版 XUDP 的 Global ID & UoT Migration 有什么效果【以下内容来源

v1.8.1 以前,你用任何 UoT,假设服务端用 A 端口与多目标通信,若 TCP 断了,比如切换网络,重连后服务端会改用 B 端口。 v1.8.1 开始,你用 VLESS(包括 Mux.Cool),即使 TCP 断了,重连后服务端还是会用 A 端口。

尤其是,对 P2P 有奇效。从某种程度上来说,这才是真正的 FullCone。双端 Xray-core v1.8.1+ 自动启用,无需额外配置。

可以用 NatTypeTester,先连接家里 WiFi 测一下,再连接手机热点(流量)测一下,你会发现服务端出口端口没变,挺神奇的。

7.Trojan是否可以平替VLESS答疑【以下内容来源

都是 TLS,但怎么用 TLS,是有讲究的,有句话我早就想对鼓吹 Trojan 平替 VLESS 的人说:真以为 Trojan 能用一辈子? 早在三年前的 VLESS BETA 我就给你们说过,光套一层加密并不能掩盖里面的时序特征,所以 VLESS 有 flow 机制。 但是呢,以前的 GFW 没上手段,简单套个 TLS 在实践上的确还可以用,就像 WSS ALPN 一直很明显,但以前它能用。 它们还能用,我就没必要提前出牌,等 GFW 上了手段,我再继续出牌,并且不推荐大家再用旧的 WS、无 flow 等。

有一点需要再次强调,我支持的始终是 TLS 上的百花齐放,而不是 TCP 上的,原因以前说过很多,可以去 v2ray 翻翻。 前段时间不是有个论文嘛,算了不想说了,有空时再评论。 #14

8.各协议 2023 现状【以下内容来源

还是简单说一下各协议 2023 现状(对于中国大多数地区)

  1. SS 全随机数类秒封 IP;IPv6 不一定封,因人品而异;绕过“省钱规则”曾经不封,目前不知道,但若流行了肯定会封,参考 SSR
  2. Trojan、WSS 隔天封端口;Cloudflare 不封但干扰会很严重,因地区而异
  3. 黑名单是单连接 TLS in TLS 握手典型特征,因为用强 padding(Vision)或开 mux 就能绕过,注意不要让猪队友客户端连接
  4. REALITY 类偷白名单域名的话即使有上述特征也不封;甲骨文等太黑的 IP 段偷大厂/偷别人不一定连得上
  5. Hysteria、TUIC 不一定封,因配置、地区而异;可能会遇到 QoS 限速,因运营商而异;总之就是使用体验严重因人而异

所以你可以看到以前的流行协议在今年是什么样的存活状况,事实上今年自建的大都是新协议,非 IPLC 中转用的协议原理也没差 你的主观印象中“今年能连接国外网络的人数并没有减少”,严格来说就是因为自建,一些人把它透明化了,卖中转给机场和个人 #15

Debian 11 使用 Docker 安装 Mailcow 自建域名邮箱

Debian 11 使用 Docker 安装 Mailcow 自建域名邮箱

本文将指导如何在 Debian 11 下使用 Docker 安装 Mailcow 搭建自建邮箱。

PS:本文同时适用于任何可安装 Docker 的 Linux 发行版。
本站注:使用黑暗模式查阅本文更直观。

什么是电子邮箱?

电子邮箱,即电子邮件,就是 Email,是指一种由一寄件人将数字信息发送给一个人或多个人的信息交换方式,一般会通过互联网或其他电脑网络进行书写、发送和接收信件,目的是达成发信人和收信人之间的信息交互。一些早期的电子邮件需要寄件人和收件人同时在线,类似即时通信。(Wikipedia

国内用户一般会使用网易(@163.com)、腾讯(@qq.com)等免费邮箱服务,国外用户一般会使用 Google(@gmail.com)、Yahoo(@yahoo.com)、Microsoft(@outlook.com)等免费服务。

为什么要自建邮箱?

首先,你的数据是你自己的,你的隐私应当得到保护,而不是那些垄断巨头公司的,几乎所有市面上的免费邮箱服务,都是以牺牲你的隐私和数据为代价,利用你的大数据来进行广告行为分析来盈利,那么,你愿意把你自己的数据交付给和你素不相识的第三方么?

其次,看本博客的读者,几乎人手一个域名,人手一只 VPS,那为何不把现有资源利用起来做一些很酷的事情呢?

自建邮箱的优势和劣势

那么,会有小伙伴指出,市面上也有收费的邮箱呀,比如国内一些大厂的「企业邮箱」,为什么不用收费服务呢?我们就自建邮箱,免费邮箱和收费邮箱做一个简单的表格对比:

对比 自建邮箱 免费邮箱 收费邮箱
隐私性
维护难度
价格 中 – 高
使用成本
隐性成本* 极高

着重指出一下我所强调的隐性成本:

因为免费和收费的邮箱服务,你的数据都是保存在第三方,你没有服务器的权限,你的帐号都是别人服务器里的冷冰冰的数据库,那么,你邮箱的提供商可以:

  1. 随时用各种理由关停你的服务,无论是合法的还是莫须有的原因,比如这里的例子
  2. 随时把你的资料卖给第三方,你作为最终用户是不可能知道的,比如?
  3. 随时面临倒闭关门从而永久丢失数据的风险,比如曾经的雅虎中文邮箱。

这些成本是你使用第三方服务的时候可能没有考虑过的,而自建邮箱服务的话,这个隐性成本我们是可控的:

  1. 你可以控制你的域名,只要选对有良好信誉的注册局和注册商,每年稳定续费并不做违反 ToS 的事情,域名一般不会被强制暂停;
  2. 你可以选择你的服务器供应商,只要选对有良好信誉的供应商,每月稳定续费并不做违反 ToS 的事情,服务器一般不会被强制暂停;
  3. 你可以每天备份你的数据,自己做数据容灾备份,不丢失任何重要的资料。

自建邮箱需要准备的资料

首先,你需要有一个你「完全拥有使用权限」的「国际化」的域名,我们不推荐使用任何小国家的国别后缀,不然哪天你域名怎么没的都不知道,这里主要还是推荐如下几个稳如狗的 gTLD 后缀:

  • .com
  • .net
  • .org

其次,你需要一台服务器或 KVM / Xen 构架的 VPS,按照官网的说法,推荐的最小配置要求如下:

Resource mailcow: dockerized
CPU 1 GHz
内存 最低 6 GiB + 1 GiB swap (实际测试 4 GiB 内存也足够)
硬盘 20 GiB (不包含邮件的占用)
系统 x86_64

并且从防火墙放行这几个 TCP 端口:

服务 协议 端口 容器名
Postfix SMTP TCP 25 postfix-mailcow
Postfix SMTPS TCP 465 postfix-mailcow
Postfix Submission TCP 587 postfix-mailcow
Dovecot IMAP TCP 143 dovecot-mailcow
Dovecot IMAPS TCP 993 dovecot-mailcow
Dovecot POP3 TCP 110 dovecot-mailcow
Dovecot POP3S TCP 995 dovecot-mailcow
Dovecot ManageSieve TCP 4190 dovecot-mailcow
HTTP(S) TCP 80/443 nginx-mailcow

请注意,因为垃圾邮件滥用的原因,很多国外的 VPS 商家并不允许架设邮件发送服务器,并且默认 25 端口的出口方向是屏蔽的,请自行咨询厂商。

安装 Docker 和 Docker Compose

请参考本站教程

设置 DNS 解析记录

我们假设你的邮箱服务器需要使用域名 mail.example.com,你想搭建 username@example.com 的邮箱;

然后你的服务器 IPv4 为 192.0.2.25,IPv6 为 2001:db8::25,那么请预先做好如下解析:

域名 解析类型 解析值
mail.example.com A 192.0.2.25
mail.example.com AAAA 2001:db8::25
example.com MX 10 mail.example.com.
example.com TXT “v=spf1 mx ~all”
_dmarc.example.com TXT “v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;”
autodiscover.example.com CNAME mail.example.com.
autoconfig.example.com CNAME mail.example.com.

本站注:
案例 apihub.top (参考上述配置)最终配置如图:

请注意某些 DNS 厂商的控制面板添加 MX 和 CNAME 记录时不需要输入最后的点号,添加 TXT 记录时不需要最前面和最后面的引号。

另外需要联系你的 VPS 厂商,设置 PTR 记录,即 IP 反向解析,请设置 192.0.2.25 和 2001:db8::25 的 PTR 记录为 mail.example.com. 提高邮件到达率。

安装 Mailcow

首先我们获取 Mailcow 的安装代码:

apt install git -y
cd /opt
git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized 

然后生成配置文件,请注意使用 FQDN (比如 mail.example.com) 作为 hostname:

bash generate_config.sh 

按照提示输入自己的需求后即可生成好配置文件 mailcow.conf,如有需要可以自己修改这个文件。

然后拉取 Docker 镜像并启动

docker compose pull
docker compose up -d 

耐心等待几分钟后即可访问 https://mail.example.com/ 默认用户名 admin 默认密码 moohoo,建议立马修改并开启 2FA 两步验证确保安全。

添加域名和邮箱

进入 Mailcow 后台后,我们可以在顶部的 Configuration > Mail Setup 里添加域名

在左侧的 Domains tab 里选择 +Add domain 添加域名:

按照自己的要求填入各种设置:

如果需要立马生效 Web 客户端,可以选择 Add domain and restart SOGo

开启 DKIM 并添加 DNS 记录

开启 DKIM 后邮件发信到达率更高,你可以登录 Mailcow 后台后在 Configuration > ARC/DKIM keys 查看你域名的 dkim 记录值:

右边那一串 v=DKIM1;k=rsa;t=s;s=email;p= 的 2048 位字符即你的 DKIM 值,如果未开启,可以在下方输入域名,选择 2048 位,然后点 + Add 按钮添加

默认添加完域名后即开启了 DKIM,且 Selector 设置为 dkim,然后我们需要添加如下 DNS 记录:

域名 解析类型 解析值
dkim._domainkey.example.com TXT “v=DKIM1;k=rsa;t=s;s=email;p=blablablablablabla”

某些 DNS 厂商的后台可能无法直接添加 2048 位 DKIM 的 TXT 记录,因为 TXT 类型的 DNS 记录最大长度为 255 个字符,那么请手工截断成两个 TXT 记录,第一个需要 255 个字符,第二个记录为剩下的字符串

添加邮箱用户

我们可以在 Mailboxes 这个 tab 里选择 +Add mailbox 按钮添加用户:

按要求提示填写即可:

测试邮件

我们使用刚开的用户登录 Mailcow 自带的 SOGo,默认情况下地址为 https://mail.example.com/SOGo/
或者点击右上角 “应用” 下的 “Webmail”。

首先,测试接受邮件,使用任何外部邮箱给 username@example.com 发一封邮件,看看是否正常收到邮件。

然后我们测试发送邮件,在 mail-tester.com 发送一封 Plain Text 格式的测试邮件,稍等片刻后即可查看你的邮件分数,我们可以看到,严格按照本文教程搭建的自建邮箱服务评分可以是 10 分:

Mailcow 的更新和备份

Mailcow 的更新只需执行 update.sh 脚本即可:

cd /opt/mailcow-dockerized
./update.sh 

按照提示更新仓库文件:

然后再次执行 ./update.sh 更新 Mailcow,提供提示 Are you sure you want to update mailcow: dockerized? All containers will be stopped. [y/N] 输入 y 然后按回车:

然后耐心等待 Docker 更新并重启容器,并且可以选择删除旧的容器:

你也可以使用 docker system prune 命令清除无用的 Docker 镜像。

Mailcow 的备份也自带脚本,我们只需进入目录执行 ./helper-scripts/backup_and_restore.sh 即可:

假设你需要备份到 /opt/backup 目录

cd /opt/mailcow-dockerized
MAILCOW_BACKUP_LOCATION=/opt/backup
./helper-scripts/backup_and_restore.sh backup all 

建议使用定时脚本每天定时备份并同步到第三方机房加密保存

一个简单的 crontab 定时脚本如下

5 3 * * * cd /opt/mailcow-dockerized/; MAILCOW_BACKUP_LOCATION=/opt/backup /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all 

具体备份命令可参考官方教程

Mailcow 的迁移

有时候我们需要更换服务器,因为基于 Docker 安装,迁移 Mailcow 是个很简单的事情。

首先,在需要迁移的服务器安装 Docker 和 Docker Compose,并确保两边的版本一致,然后停止 Docker 服务:

systemctl stop docker.service
systemctl stop docker.socket 

使用 systemctl status docker 命令检查下 Docker 的状态:

然后从原来的机器把 Docker 容器和挂载的 Volumes 同步到新的机器:

新旧机器均需要安装 rsync

apt install rsync -y 

旧的机器生成一个 SSH Key:

ssh-keygen -t ed25519 

然后把 /root/.ssh/id_ed25519.pub 文件内容加到新机器的 /root/.ssh/authorized_keys

然后同步 Mailcow 文件和 Docker 挂载的 Volumes:

rsync -aHhP --numeric-ids --delete /opt/mailcow-dockerized/ root@新机器:/opt/mailcow-dockerized
rsync -aHhP --numeric-ids --delete /var/lib/docker/volumes/ root@新机器:/var/lib/docker/volumes 

然后在原来的机器停止 Mailcow 容器:

cd /opt/mailcow-dockerized
docker compose down 

然后再次执行一次同步:

rsync -aHhP --numeric-ids --delete /opt/mailcow-dockerized/ root@新机器:/opt/mailcow-dockerized
rsync -aHhP --numeric-ids --delete /var/lib/docker/volumes/ root@新机器:/var/lib/docker/volumes 

然后在新的机器启动 Docker 服务:

systemctl start docker.service 

然后在新的机器启动 Mailcow 容器:

cd /opt/mailcow-dockerized
docker compose pull
docker compose up -d 

记得迁移之前需要修改好 DNS 记录,解析到新的服务器 IP 即可。

这个迁移方法理论上适合任何使用 Docker 安装的软件

问题集锦

  • 提示:too many colons in address
    docker compose up -d
    WARN[0000] The "WATCHDOG_NOTIFY_EMAIL" variable is not set. Defaulting to a blank string.
    1 error(s) decoding:
    
    * error decoding 'Ports': Invalid ip address :: address ::: too many colons in address

    解决

       - "${HTTPS_BIND:-:}:${HTTPS_PORT:-443}:${HTTPS_PORT:-443}" 
       - "${HTTP_BIND:-:}:${HTTP_PORT:-80}:${HTTP_PORT:-80}" 
    
    # 修改为
    
       - "80:80"
       - "443:443"
  • 提示:Pool overlaps with other one on this address space
     Network mailcowdockerized_mailcow-network  Error                                                                                                                                   0.0s
    failed to create network mailcowdockerized_mailcow-network: Error response from daemon: Pool overlaps with other one on this address space

    解决
    由于 当前 Docker 网络已占用 172.22.1 网段,导致无法启动本程序。

    # 查看网络
    docker network ls  | awk '{print $1}' | xargs docker inspect | grep -B 15 172.22
    
    # 找出 `"Name"` 选项中的网络,先停止该容器,待启动本项目,再启动该容器。

给docker设置个代理

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo touch /etc/systemd/system/docker.service.d/http-proxy.conf

if ! grep HTTP_PROXY /etc/systemd/system/docker.service.d/http-proxy.conf;
then
cat >> /etc/systemd/system/docker.service.d/http-proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://127.0.0.1:3128/" "HTTPS_PROXY=http://127.0.0.1:3128/" "NO_PROXY=localhost,127.0.0.1,docker-registry.somecorporation.com"
EOF
fi

# Flush changes:
sudo systemctl daemon-reload
#Restart Docker:
sudo systemctl restart docker
#Verify that the configuration has been loaded:
sudo systemctl show --property=Environment docker
# 像这样:Environment=HTTP_PROXY=http://127.0.0.1:8081/ NO_PROXY=localhost,127.0.0.1,docker-registry.so

systemd 设置环境变量

设置 systemd 的环境变量,有如下几种方式:

  • 1. 在 xxx.service 通过 Environment="MY_VAR_1=VAR_1_VALUE" 设置变量
  • 2. 在 xxx.service 通过 EnvironmentFile=/opt/workspace/my_env 指定配置文件
  • 3.systemctl edit xxx.service 或手动创建 /etc/systemd/system/xxx.service.d/override.conf 文件进行配置

同一个变量,在多个方式同时配置,会存在覆盖。建议只使用一种方式。

方式 1 Environment=

编辑 systemd 的 service 文件,添加 Environment= 形如下:

  • [Service]
  • Environment=“MY_VAR_1=VAR_1_VALUE”
  • Environment=“MY_VAR_2=VAR_2_VALUE”

上述添加了两个环境变量:MY_VAR_1=VAR_1_VALUE 和 MY_VAR_2=VAR_2_VALUE

如需修改环境变量,即修改 service 文件,需要重新 reload

  • systemctl daemon-reload

方式 2 EnvironmentFile=

编辑 systemd 的 service 文件,添加 EnvironmentFile= 形如下:

  • [Service]
  • EnvironmentFile=/opt/workspace/env_test.env
  • EnvironmentFile=-/opt/workspace/env_test_not_exist.env

上述指定了两个设置环境变量的文件:/opt/workspace/env_test.env 和 /opt/workspace/env_test_not_exist.env
需要注意的是,第二个 EnvironmentFile 使用 - 在目录前,作用是忽略文件不存在。

创建 /opt/workspace/env_test.env 格式如下

  • MY_VAR_1=VAR_1_VALUE
  • MY_VAR_2=VAR_2_VALUE

方式 3 创建 xxx.service.d/override.conf

创建这个文件,有两种方式,执行 systemctl edit xxx.service 后,进入 nano 编辑界面保存成文件即可。或者在 xxx.service 同目录下,创建 xxx.service.d 文件夹,在该文件夹下,创建 override.conf (文件名随便,一般为 override.conf )。

创建的文件格式如下:

  • [Service]
  • Environment=“MY_VAR_1=VAR_1_VALUE”
  • Environment=“MY_VAR_2=VAR_2_VALUE”

以 Debian 系统为例,一般 xxx.service 文件在 /etc/systemd/system/ 下,
所以创建的文件路径为 /etc/systemd/system/xxx.service.d/override.conf

引用:

How to set environment variable in systemd service?

PVE OP overlay分区扩容

官方镜像硬盘空间只有一百多兆,如果安装比较多的插件空间会比较紧张,需要扩容,网上找到使用最多的教程方法,不知道为什么在我这里一直无法成功扩容,常见教程都是将硬盘剩余空间新建分区,然后迁移overlay分区文件到新分区,再挂载为外部/overlay,或者迁移根目录下所有内容再挂载为根目录/,这两种我试了不下5次,均告失败,还有按openwrt官方方法也是未能成功扩容,最后找到较少见的直接扩容原overlay空间的方法,好不容易成功扩容,记录一下,以防忘记。

1. 安装必要工具

opkg install losetup parted cfdisk block-mount fdisk resize2fs

2. 调整硬盘大小

在pve中调整硬盘大小,然后启动虚拟机。

3. 扩容操作

ssh登录openwrt,运行以下命令:

cfdisk #查看硬盘分区信息,检查是不是有一个调整硬盘大小后多出来的free space,一般overlay目录挂载的是/dev/sda2

parted /dev/sda

print #查看硬盘信息,第二个分区即sda2,注意现在空间大小(size)

resizepart 2 100% #修改第二个分区sda2大小为100%,即将所有free space划入sda2

print #检查看空间大小是不是变了

losetup #记住/dev/loop0的offset偏移值

losetup -o offset偏移值 /dev/loop100 /dev/sda2 #offset偏移值换成上一命令显示的offset值,loop100可以改成其他,只要不跟现有loop设备重复就行

e2fsck /dev/loop100 #检查文件系统,一路按y确认就可以

resize2fs /dev/loop100 #修改分区空间大小

reboot #重启系统后可使用df -h命令检查overlay是不是变大了,或者进入软件安装界面查看剩余空间

至此完成overlay分区扩容。

Proxmox VE PCIe 直通 intel 核显开启 SRIOV

Proxmox VE PCIe 直通 intel 核显开启 SRIOV
cokebar 2024-04-04 17:35 2024-04-04 17:40 PVE 没有评论
主要参照:

https://pve.proxmox.com/wiki/PCI(e)_Passthrough

https://github.com/strongtz/i915-sriov-dkms

适用于Proxmox VE 8.x版本,内核6.1~6.5.

一、编译安装i915-sriov-dkms
首先确保启用了pve-no-subscription源和debian源,推荐先把debian源换成国内源 如清华源。

然后先更新一下软件包,并安装其他依赖,主要是需要确保内核头文件和内核版本一致,所以干脆全更新到最新版本:

Shell
apt update
apt upgrade -y
apt install -y build-* dkms git pve-headers sysfsutils
全部安装完毕后,需要先重启一下:

Shell
reboot
(有能力的可以尝试卸载旧版本内核和头文件,以节省空间)

重启好以后,接下来下载源码到指定位置:

Shell
cd /usr/src
git clone https://github.com/strongtz/i915-sriov-dkms.git
mv i915-sriov-dkms i915-sriov-dkms-6.1
找到/usr/src/i915-sriov-dkms-6.1/dkms.conf文件,修改如下两行,修改前为:

PACKAGE_NAME=”@_PKGBASE@”
PACKAGE_VERSION=”@PKGVER@”
修改后:

PACKAGE_NAME=”i915-sriov-dkms”
PACKAGE_VERSION=”6.1″
最后编译dkms模块并安装:

Shell
dkms install -m i915-sriov-dkms -v 6.1 –force
二、修改系统设置
定位到/etc/default/grub文件,打开编辑如下高亮这一行:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=”quiet”
GRUB_CMDLINE_LINUX=””
把高亮的这一行修改为:

GRUB_CMDLINE_LINUX_DEFAULT=”quiet intel_iommu=on iommu=pt intel_iommu=on i915.enable_guc=3 i915.max_vfs=7″
打开/etc/modules文件,添加下面高亮的行:

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with “#” are ignored.
# Parameters can be specified after the module name.

vfio
vfio_iommu_type1
vfio_pci
#vfio_virqfd #not needed if on kernel 6.2 or newer
PVE 8.1内核版本是6.5,大于6.2,最后一行不用写,故注释掉。

运行如下命令,查看显卡的PCI总线地址:

Shell
lspci | grep VGA
命令大致如下:

00:02.0 VGA compatible controller: Intel Corporation Raptor Lake-P [Iris Xe Graphics] (rev 04)
前面的 00:02.0 就是总线地址,不过是缩写地址,省略了前缀 0000: ,完整的是 0000:00:02.0 ,记住这个地址。

添加下面一行到 /etc/sysfs.conf 文件中:

devices/pci0000:00/0000:00:02.0/sriov_numvfs = 7
上面命令中的 0000:00:02.0 就是前面获取的显卡的PCI总线地址,替换成你自己的就可以了。一般情况下intel核显都是 0000:00:02.0 这个地址,不用改。

运行命令:

Shell
update-grub
update-initramfs -u -k all
最后重启:

Shell
reboot
这样就完成了,最后看一下效果,下图中0000:00:02.1~0000:00:02.7这7个就是SRIOV虚拟出来的显卡:

相关文章:

Proxmox VE(PVE)8.0使用CT模板创建LXC版docker服务

Proxmox VE(PVE)8.0使用CT模板创建LXC版docker服务

前边已经分享了pve的安装,pve下安装爱快(ikuai)以及pve下安装openwrt实现旁路由,还想要弄一个docker来跑一些其他的服务,docker的安装有两种方式,一种是装一个linux的虚拟机,然后在里边来跑docker,另一种就是今天要介绍的使用CT模板来创建LXC容器跑docker。

CT模板下载

我这里使用的是debain12来当作模板,可以在pve里下载该模板。

pve ct debain

创建CT

常规

点击创建CT,这里的主机名随便给一个,因为我这里是要专门来运行docker,所以我这里填:docker, 密码是这个容器的登录密码,一定要牢记。另外要把无特权的容器取消勾选

pve ct docker common

模板

模板选择下载的debian模板

pve ct docker template

磁盘

磁盘大小根据自己的实际需要给

pve ct docker disk

CPU

cpu把j4125的4核都给过去

pve ct docker cpu

内存

我这里先给2GB,后续根据需求再添加

pve ct docker ram

网络

我这里手动指定了ip,可以使用dhcp自动分配ip

pve ct docker network

DNS

dns默认

pve ct docker dns

确认

刚才设置的一些信息的预览

pve ct docker confirm

创建完成后先不要开机,还需要一些其他的一些配置。

功能

在功能里勾选NFS等选项

pve ct docker function

LXC配置文件

还需要进入pve的shell,对刚创建的LXC容器的配置文件进行修改,位置:/etc/pve/lxc,此时里边应该只有1个配置文件,文件名对应创建的lxc容器在pve里的id。我的是102.conf

需要在后边再添加几行:

 

lxc.apparmor.profile: unconfined # 表示容器内的进程将不受任何 AppArmor 限制
lxc.mount.auto: cgroup:rw
lxc.mount.auto: proc:rw
lxc.mount.auto: sys:rw
lxc.cap.drop:  # 用于指定容器内进程的能力限制,允许进程执行一些特定的操作,例如修改系统时间、挂载文件系统等
lxc.cgroup.devices.allow: a

完整的配置如下:

 

root@pve:/etc/pve/lxc# cat 102.conf 
arch: amd64
cores: 4
features: fuse=1,mount=nfs;cifs,nesting=1
hostname: docker
memory: 4096
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.1.253,hwaddr=BA:64:EF:29:04:A6,ip=192.168.1.22/24,type=veth
ostype: debian
rootfs: local-lvm:vm-102-disk-0,size=30G
swap: 512
lxc.apparmor.profile: unconfined
lxc.mount.auto: cgroup:rw
lxc.mount.auto: proc:rw
lxc.mount.auto: sys:rw
lxc.cap.drop: 
lxc.cgroup.devices.allow: a

配置完成后就可以正常启动该容器了。

更换源

源文件路径:/etc/apt/sources.list,替换为下边的内容。

root@docker:/etc/apt# cat sources.list
deb https://mirrors.ustc.edu.cn/debian bookworm main contrib
deb https://mirrors.ustc.edu.cn/debian bookworm-updates main contrib
deb https://mirrors.ustc.edu.cn/debian-security bookworm-security main contrib

查看是否替换成功,执行命令apt update:

root@docker:/etc/apt# apt update
Hit:1 https://mirrors.ustc.edu.cn/debian bookworm InRelease
Get:2 https://mirrors.ustc.edu.cn/debian bookworm-updates InRelease [55.4 kB]
Get:3 https://mirrors.ustc.edu.cn/debian-security bookworm-security InRelease [48.0 kB]
Get:4 https://mirrors.ustc.edu.cn/debian-security bookworm-security/main amd64 Packages [148 kB]
Hit:5 https://download.docker.com/linux/debian bookworm InRelease
Fetched 251 kB in 1s (228 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
51 packages can be upgraded. Run 'apt list --upgradable' to see them.

可见已经替换成功。

SSH登录

默认情况下只能通过pve的控制台进行登录,无法在其他地方进行登录。

修改sshd的配置文件,文件路径:/etc/ssh/sshd_config,添加下边的内容:允许root登录,开启key登录:

PermitRootLogin yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

如果只想使用key登录,禁止密码登录可以再添加一行:PasswordAuthentication no 。根据自己需求添加。

时区设置

默认情况下是0时区:

root@docker:~# date 
Sun Mar 24 07:04:09 UTC 2024
root@docker:~# date -R
Sun, 24 Mar 2024 07:04:11 +0000

修改为北京时间:

root@docker:~# timedatectl set-timezone Asia/Shanghai
root@docker:~# timedatectl
               Local time: Sun 2024-03-24 15:06:22 CST
           Universal time: Sun 2024-03-24 07:06:22 UTC
                 RTC time: n/a
                Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no

可以看到已成功设置为北京时间了。

整个LXC容器已设置完成。

解决Linux navidrome 下音乐乱码的问题:

解决Linux下音乐乱码的问题:

MP3文件乱码的原因:

这个问题出现在mp3文件里,由于大陆大多数MP3文件都是用GBK/GB18030编码写入标签信息的,而大多数的linux播放器默认以utf-8编码读取,这就产生了乱码。

解决方法:

使用Mutagen来修改Mp3文件的标签信息,具体方法如下(只针对GBK/GB18030编码的情况):

安装Mutagen:

https://www.geeksforgeeks.org/how-to-install-mutagen-for-python-on-linux/

sudo apt-get install python-mutagen

sudo pip3 install mutagen

在终端执行:

mid3iconv -e gbk *.mp3(转换当前目录下的所有 mp3)

想转换当前目录及子目录则执行:

find . -iname “*.mp3” -execdir mid3iconv -e gbk {} \;

解决Linux下音乐乱码的问题:

gsettings set org.gnome.gedit.preferences.encodings auto-detected “[‘UTF-8′,’GB18030′,’GB2312′,’GBK’,’BIG5′,’CURRENT’,’UTF-16′]”

然后再用gedit打开文件

修改PVE容器CT镜像源

修改PVE容器CT镜像源

原文参照

http://mirrors.ustc.edu.cn/help/proxmox.html

CT Templates

另外,如果你需要使用 Proxmox 网页端下载 CT Templates,可以替换 CT Templates 的源为 http://mirrors.ustc.edu.cn

具体方法:将 /usr/share/perl5/PVE/APLInfo.pm 文件中默认的源地址 http://download.proxmox.com 替换为 https://mirrors.ustc.edu.cn/proxmox 即可。

可以使用如下命令:

cp /usr/share/perl5/PVE/APLInfo.pm /usr/share/perl5/PVE/APLInfo.pm_back
sed -i 's|http://download.proxmox.com|https://mirrors.ustc.edu.cn/proxmox|g' /usr/share/perl5/PVE/APLInfo.pm

针对 /usr/share/perl5/PVE/APLInfo.pm 文件的修改,执行systemctl restart pvedaemon 以生效

CT无法启动

在第一次启动CT时,我遇到了无法启动问题,报错信息为WARN: old systemd (< v232) detected, container won't run in a pure cgroupv2 environment! Please see documentation -> container -> cgroup version. TASK WARNINGS: 1,翻阅PVE官方文档未找到想要答案,只注意到这个错误应该与systemd有关,但我的主机systemd版本为247,不应该版本过低。

最后运行apt list --upgradable时发现systemd可以从247.3-7+deb11u4升级到247.3-7+1-pmx11u1,后者来源于promox源,前者来源与debian源,意识到可能是debian源的systemd不支持CT所需要的特性,于是apt upgrade and reboot,重启后CT启动成功。

PVE更新系统

apt updgrade过后再次apt upgrade ,发现有3个包显示kept backed,虽然可以正常使用,但逼死强迫症。通过PVE论坛帖子发现,我的更新方式有问题。

一般debian的服务器为了稳定都选择使用apt updgrade来更新系统,但是PVE需要使用apt dist-upgradeapt updgrade会破坏PVE依赖。PVE的web面板里面的更新按钮就是使用apt dist-upgrade,PVE官方手册也推荐它。