DC的开发日志

由于Docker Hub主动退出市场，导致国内不能方便的拉取docker镜像，故计划在内网使用Nexus Repository架设私有仓库，行pull through cache之职能，将下载的镜像/包缓存下来以便多次部署供内网的多设备使用，降低对国内高校镜像站的流量使用；同时考虑到PyPI也可能发起制裁导致不能使用，也计划建立PyPI的内网仓库。 目标 架设Nexus Repository OSS 通过高校镜像站提供的HTTP代理缓存Docker Hub 同上，缓存PyPI仓库 Nexus Repository OSS部署 Nexus Repository对Java 8以上的支持并不是特别好，有挺多坑需要留意。根据官网文档部署的情况下还需要注意以下几点： Java版本选择 目前个人建议使用Java 11，因为当前LTS版本中Java 8太老而Java 17暂不支持OrientDb。我懒得专门部署一个外部数据库所以选择了Java 11，需要进行的改动最小。 # 使用Java 11以上版本的报错 java.lang.IllegalStateException: The maximum Java version for OrientDb is Java 11. Please check current Java version meets this requirement. JVM选项修改 根据文档，使用Java 9以上版本时需要注释和取消注释掉{NEXUS_HOME}\bin\nexus.vmoptions中的部分内容，理论上来说根据配置文件中的说明进行修改即可。但上述部分在随安装包附带的版本中存在缺失若干等号=和路径不正确的问题，即使按照配置文件中的说明也无法直接使用。修改后的JVM配置文件如下，主要是缺少等号导致选项不能正确解析，再次说明对Java 8以上版本何等不上心，几年前的问题在最新版本中仍未修正。 -Xms2703m -Xmx2703m -XX:MaxDirectMemorySize=2703m -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=../sonatype-work/nexus3/log/jvm.log -XX:-OmitStackTraceInFastThrow -Djava.net.preferIPv4Stack=true -Dkaraf.home=. -Dkaraf.base=. -Dkaraf.etc=etc/karaf -Djava.util.logging.config.file=etc/karaf/java.util.logging.properties -Dkaraf.data=../sonatype-work/nexus3 -Dkaraf.log=../sonatype-work/nexus3/log -Djava.io.tmpdir=../sonatype-work/nexus3/tmp -Dkaraf.startLocalConsole=false -Djdk.tls.ephemeralDHKeySize=2048 # # additional vmoptions needed for Java9+ # --add-reads=java....

由于手头的一些设备不太方便甚至不能配置DoH，所以准备在家中的局域网里自建一个DNS代理，将DNS请求转为DoH进行查询，在保障隐私的同时也有着良好的兼容性和可维护性。 在习惯性地开始动手造轮子的同时还是调研了下，dnscrypt-proxy作为比较成熟的软件已经能满足我的需求，且配置方便灵活，资源占用也不高，所以干脆放弃造轮子，直接用现成的。 安装dnscrypt-proxy 虽然Ubuntu仓库提供了dnscrypt-proxy，但毫不意外地进行了“定制”。为了省去debug的功夫，建议按照官方wiki的Linux安装指南手动安装一遍。文档写得还是蛮详细的，这里就不赘述安装流程了，我照着步骤一遍过了。 配置dnscrypt-proxy 其实官方wiki里写得也比较详细了，这里我提几个我格外留意的配置项吧 DNS服务器 我注释掉了所有sources，只使用手动配置的static服务器。一方面是访问官方的sources列表存在困难，而第三方提供的列表很难完全信任；另一方面是家庭使用情况下，通常也只用的上那么几个固定的DNS服务器，手动配置一下反而更方便维护和排错。 我使用的是Cloudflare和NextDNS的DoH服务，手动生成了复数个使用不同IP的备选项，当无法正确解析DoH服务器的IP时至少有个兜底。通过这个工具可以计算所需的形如sdns://的DNS stamp，比如我就在默认的1.1.1.1之外给Cloudflare DoH加了cloudflare-dns.com的备选项。 dnscrypt-proxy会定期测试服务器延迟，默认采用的是lb_strategy = 'p2'，从最快的2个服务器中随机选择。也是出于这一考虑我就没在dnscrypt-proxy里配置阿里云DNS作为fallback——毕竟近水楼台，响应肯定永远是最快的。 速度优化 官方wiki里提到了三种速度优化：拦截IPv6、DNS缓存和加密套件。 拦截IPv6(block_ipv6 = true)说实话我没测试出来很显著的性能提升，虽然家里现在没弄IPv6，但考虑到之后可能会用上，加之我还是希望给局域网里的所有设备完整的DNS响应，所以最后还是没配置拦截。 默认的缓存策略会在内存中缓存最近4K条查询，TTL看起来也相对合理。家用场景下更高的cache_size似乎作用不大，可惜用不完给虚拟机配的1GB内存了。 加密套件目前也相对无所谓，我用的x86虚拟机承载DNS服务，不像在树莓派或者路由器的ARM处理器上要省着用计算资源。所以按默认配置以免之后还要查兼容性问题。 Cloaking 简单来说可以类比hosts文件，我给几台局域网下的关键服务器配置了便于访问的域名，省的给每台新机器一个个改hosts。 其它 虽然dnscrypt-proxy提供了丰富的blocking、filtering、forwarding等等功能，但是我把它们大多禁用了。我需要的只是一个安全可靠的DNS服务器，它目前做好域名解析的工作就够了；至于拦截广告和阻止访问某些网站等等，这些工作我觉得可以也应该由设备/应用和它们的使用者自己决定。 应用自建DNS 各个运行桌面/服务器OS的机器都好说，配置自建的DNS服务地址作为首选DNS，备选填上阿里云DNS以防整活失败全家断网。 各个“智能”设备则只能靠路由器DHCP分发DNS了，在路由器配置里同样配置自建DNS首选，然后重启路由器让所有设备重新联网。某些设备可能比较固执，而且我也不知道这些黑箱里到底是怎么执行网络相关逻辑的，总之还是把几个“最需要它们能正常运行”的设备本身也重启了一下。 目前能测试到的DNS请求都走自建DNS了，缓存生效的时间内能立即响应，需要通过DoH请求的域名会慢一点，但实际使用起来没啥感觉。总之我已经在没有通知任何人的情况下把家里路由器上DNS改了，如果这几天家里人没反馈网络有问题的话那就当一切安好了。

手头有两个临到期的服务器闲置中，正好拿来实验一下写着玩的SSH“蜜罐”。方法就是伪装成OpenSSH Server在22端口上监听，但对所有请求均返回密码错误，同时记录下此次登入使用的用户名、密码、客户端版本及源IP地址，希望能借此捞到一点密码词典，同时对收集到的数据进行一点统计分析。 蜜罐写的很挫，就暂时不公开代码了。总共钓了大概一个月的鱼，有一些有趣的统计数据还是可以分享下的。 登入尝试次数 澳大利亚：213941，日均7131次 中国大陆：102403，日均3413次 两台服务器分别位于中国大陆和澳大利亚，没有DNS记录指向它们，应该单纯就是被扫到22端口了。数量在意料之中，改端口+套防火墙还是有必要的。 用户名TOP10 澳大利亚 中国大陆 1 root (84.97%) root (71.82%) 2 admin (1.62%) admin (3.48%) 3 user (1.02%) user (2.56%) 4 ubuntu (0.73%) ubuntu (1.62%) 5 test (0.73%) test (1.43%) 6 oracle (0.51%) oracle (1.04%) 7 ftpuser (0.42%) ftpuser (0.96%) 8 usuario (0.38%) debian (0.90%) 9 debian (0.36%) test1 (0.85%) 10 test1 (0.34%) usuario (0.84%) 同样意料之中的优先想拿下root，但稍微意料之外的是出现频率这么高，跟第二名出现了巨大的断层。usuario查了一下是西班牙语的user之意。 密码TOP10 澳大利亚 中国大陆 1 123456 (1.99%) 123456 (2.09%) 2 admin (0....

在我的Windows启动项里始终有几个名为“Program”的程序，看起来是已经卸载的软件残留，而且禁用了没什么影响。不过看着碍眼，决定处理掉它们。 在任务管理器-启动的标题栏右键，勾选“命令行”，此时能看到启动项对应的命令行。果不其然是因为Program Files忘记加引号导致被截断。令人难绷的是连微软自家的Teams安装程序都犯了这个错，很难不嘲笑微软当年决定用Program Files彰显自家文件系统终于支持空格时给自己挖了多大坑。 同样在上图也可以看到启动项是通过何种方式添加的。通过“文件夹”方式添加的话去到开始菜单的“启动”目录，找到对应快捷方式并删除即可。 C:\Users\(USERNAME)\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp 而通过“注册表”方式添加的话需要到下列注册表位置中查找对应的注册表项： HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run HKEY_CURRENT_USER\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run 找到对应注册表项后删除即可。 当然此种方法也可以用来修复忘记加引号的启动项，类似的找到启动项把引号加上即可——当然最重要的一课可能是避免在路径中使用空格等“特殊符号”。

起这个标题可能稍微有点标题党的意思，但考虑到从澳洲往国内传输文件确实跨大洲甚至跨洋了，似乎也不算那么夸张。 起因是手头有一批数十GB起的文件需要传回国内的NAS(主要是我拍摄的风光照片，以及Llama的模型权重)，考虑到不像国内快递物流那样方便地可以直接寄U盘，通过网络传输是目前唯一可行的方案。 目前使用的方案——SFTP中转 截至成稿时最佳的传输实践还是朴实但可靠的SFTP传输。我在东亚某地的某台VPS有100M对等带宽和10GB的存储盘，将文件分卷打包后在澳洲依次上传，然后远程回国内再依次下载解压。简单记录了一下传输速度，多个文件同时上下载时基本能跑满带宽。 传输方向 单个文件 多文件并行 澳洲上传 约7.5MB/s 约11MB/s 国内下载 约5MB/s 约9MB/s 其他注意事项： 优点 稳定，没遇到过断连的情况，多数传输一次即可成功 基本能跑满中转服务器的带宽 缺点 如果中转用的服务器存储空间有限，需要分批多次上传/下载，不做自动化的话靠人守着有点费事 上传前下载后校验Hash(反复强调，虽然偶发且概率很低，但确实会出现文件损坏的情况) 使用7z的“极速压缩”对于多数文件取得了压缩时间和压缩率上的平衡，使用“标准压缩”速度显著变慢且几乎不能取得更低的压缩率 Llama参数：压缩率约78% RAW原片：压缩率约87% JPEG导出照片：显而易见的几乎无法压缩，使用“仅存储”即可 使用过但最终放弃的方案 这里还是简单记录一下使用过但放弃了的方案，以及在我的使用场景下为什么它们存在问题。 网盘中转 最先尝试以及最早放弃的方案。百度云盘就不说了，Google网盘在国内也需要额外的神秘开销才能使用。OneDrive虽然在澳洲上传速度很快，但国内直连仅100KB/s左右的下载速度不知道要下到猴年马月去。 一句话总结：国外的网盘在国内要么没法(直接)用，要么速度奇慢。 对象存储中转 与网盘类似的问题：国外的对象存储便宜(甚至有不少免费额度)，但在国内下载慢且不稳定，哪怕是套了Cloudflare也没能完全解决断连的问题；国内的对象存储更贵，而且我想尽可能利用已有的资源避免多花钱。所以这条路很快也放弃了。 反向代理 把家里某台跳板机的存储服务反向代理到东亚某地的VPS上，然后在澳洲通过反代出来的服务直接传回家。速度相当难看，最高仅有1MB/s左右。更头疼的是线路始终不稳定，传不了几GB就会断连一次，就不说是什么原因了。 HTTP中转 这里尝试过在东亚某地的VPS上搭建AList存储服务，但发现免费Cloudflare套餐限制请求大小为140MB，导致我没法通过Web控制台上传文件。于是乎还是通过SFTP上传文件，在国内用HTTP下载。问题是很显然我没法用国内特供版的Cloudflare，导致下载过程依旧避免不了的是“从国外网站下载文件”，断连问题依旧不可避。

由于WSL2在NTFS上的IO性能过于捉急，还是决定把JupyterLab环境完全挪到WSL原生的文件系统下。但是WSL默认将文件系统放在系统盘，这样我额外加的NVME SSD就成了摆设，于是需要把承载WSL文件系统的虚拟硬盘文件移动到指定的位置。查询资料后，使用原生工具进行迁移的最佳实践是“导出-挪位置-再导入”，那就按这个来吧。 导出WSL环境 WSL的每个发行版环境实际上是一个最大1TB的vhdx虚拟硬盘，可以直接使用wsl导出这个文件到某个指定目录。 wsl --list --verbose wsl --export Ubuntu-22.04 X:\WSL-Backup\Ubuntu22.vhdx --vhd 重新导入WSL环境 原本的环境我没有急着删——毕竟unregister也很方便，暂时留着以免新环境不能正常使用。这里就要注意导入上面导出的环境时需要起一个不同的名字。这里有两种方式导入：重新导入到某个指定目录，或者在上述的目录原地导入、 wsl --import Ubuntu22New X:\WSL\Ubuntu22New X:\WSL-Backup\Ubuntu22.vhdx --version 2 wsl --import-in-place Ubuntu22New X:\WSL-Backup\Ubuntu22.vhdx 但是导入过程中出现以下报错： 未指定的错误 Error code: Wsl/Service/E_FAIL 说白了，原因不明，但是在这个Github issue里找到了workaround，也就是设置默认WSL版本为WSL2后重新导入。 wsl --set-default-version 2 wsl --import Ubuntu22New E:\WSL\Ubuntu22New E:\WSL-Backup\Ubuntu22.vhdx --vhd 成功后会在指定目录下产生一个ext4.vhdx文件，顾名思义就是WSL使用的ext4文件系统了。实测在原生的文件系统里性能比跨到NTFS性能好上许多，愉快地将之前的Python venv都挪进去了——这时候就体现出虚拟环境的便利了。 设定默认发行版/用户名 设置默认发行版很简单： wsl --set-default Ubuntu22New 但导入的WSL环境不支持通过wsl直接配置默认用户名，于是需要进到环境里手动修改/etc/wsl.conf文件，添加下面的配置项： [user] default=默认用户名 重启环境后(根据微软的文档，需要在登出全部终端后等待至少8s，该环境才会shutdown)再次进入该WSL发行版，就会用设定的默认用户名登入了。 题外话 - Windows Terminal 说实话，Windows终端跟WSL融合的挺好的，目前使用没遇到问题，比起在cmd或者PowerShell里使用WSL体验要好得多，之后没什么问题的话大概会继续用下去。

Windows下的num_workers > 0报错 在Windows下新搭建的PyTorch环境中使用之前的某个课程项目进行测试时，发现设置DataLoader的num_workers大于0会导致模型训练卡死。由于GPU无占用，在JupyterLab日志中找到形如AttributeError: Can't get attribute xxx on <module '__main__' (built-in)>的报错，最后定位到DataLoader上。 注意到不少回答都认为Windows下应该将num_workers设为0，但并未解释原因，实际测试发现训练过程远比进行课程项目时慢，于是进一步搜索希望能够找到更好的解决方法。 根据这个帖子的讨论以及这篇博客介绍，由于Windows多进程机制与Linux存在区别，Windows下multiprocessing不支持使用fork创建进程，而是只能通过spawn创建新的进程；这一点差异就导致导入模块时会使用模块锁，避免多个进程导入同一模块时产生竞争。 解决方案也很简单，将原来项目的内部类(是一个数据集类)放到一个外部文件/模块中，并在原来的代码中导入它。此时multiprocessing便可以正确加载该模块，确保模块只被加载一次，然后在各个进程之间共享。 Windows下的DataLoader性能问题 通过上一节的改动，DataLoader已经可以多线程地加载数据集了。但留意到增加worker数量并不能提升训练速度，CUDA核心占用依然出现间断，且间断时CPU和磁盘使用增加。可以推测认为是DataLoader加载速度跟不上训练速度，GPU经常停下来等待数据加载。 不过这也好理解：Linux下通过fork创建进程的效率显著高于Windows，在这个issue下的讨论也普遍认为Windows的进程机制拖慢了PyTorch的效率。 “那么具体一点，能不能衡量一下Windows拖慢了多少训练速度呢？”由于之前干过一段时间性能测试，这个问题马上冒了出来。好消息是在上面提到的这篇博客中，作者给出了ta测试DataLoader的代码。而我对课程项目的代码做了简单修改，作为附加的测试项目，希望能测试真实训练场景下的性能。 Windows与(Subsystem) Linux下DataLoader性能对比 测试环境 CPU：6核心12线程 内存：32GB GPU：显存16GB 操作系统： Windows 10 Ubuntu 22.04(以WSL运行) 软件： Python 3.10 PyTorch 2.2 CUDA 11.8 测试项目 上述博客中的MNIST数据集仅加载测试 num_workers从0至12以2递增 仅测试加载数据集的用时 课程项目的AlexNet训练-验证5个epoch 涉及加载train、validation两个数据集 每个epoch在train集上训练，并在validation集上验证 (项目写的比较挫，其他hyperparameter就不写出来丢人了，主要只是测加载用时的影响) 测试记录 测试项目1 num_workers WSL用时(s) Windows用时(s) 0 16.22 16.68 2 8.38 14.49 4 4.67 10.71 6 4.00 10.56 8 3.67 11.36 10 3.47 12.22 12 4.06 14....

由于一个下篇文章会提到的性能问题，需要在WSL重新部署一套CUDA和JupyterLab环境，简单记录一下。 WSL 安装WSL组件 较新的Windows 10/11已经预装有WSL，只需要预先在BIOS中开启VT并在Windows控制面板中启用“Windows虚拟机监控程序平台”。 可以查看支持安装的Linux发行版，不过我这里是炼丹用，还是选Ubuntu了。 wsl --list --online wsl --install -d Ubuntu-22.04 在WSL中使用代理 这里使用了ZingLix的解决方案，用ta写的脚本配置环境变量，使用宿主机的HTTP代理。以下脚本的作者是@ZingLix，我只是在此引用并使用，感谢ta分享的这个好用的脚本 2024-02-24编辑： **注意：**使用. proxy.sh set或source proxy.sh set设置代理；假如使用bash执行脚本的话，环境变量不会被应用 #!/bin/sh hostip=$(cat /etc/resolv.conf | grep nameserver | awk '{ print $2 }') wslip=$(hostname -I | awk '{print $1}') port=<host_proxy_port> PROXY_HTTP="http://${hostip}:${port}" set_proxy(){ export http_proxy="${PROXY_HTTP}" export HTTP_PROXY="${PROXY_HTTP}" export https_proxy="${PROXY_HTTP}" export HTTPS_proxy="${PROXY_HTTP}" } unset_proxy(){ unset http_proxy unset HTTP_PROXY unset https_proxy unset HTTPS_PROXY } test_setting(){ echo "Host ip:" ${hostip} echo "WSL ip:" ${wslip} echo "Current proxy:" $https_proxy } if [ "$1" = "set" ] then set_proxy elif [ "$1" = "unset" ] then unset_proxy elif [ "$1" = "test" ] then test_setting else echo "Unsupported arguments....

前置工作 升级显卡驱动 安装Visual Studio的桌面应用开发套件(选做？似乎不影响PyTorch) 安装CUDA PyTorch可能需要某个指定版本的CUDA，从官网的归档里可以下载到特定版本的安装包 一路下一步直到选择组件的步骤 选择组件时留意一下CUDA以外的组件版本号，安装包附带的其他组件可能并不是最新的，此种情况下则不覆盖安装旧版本其他组件了 勾选上CUDA，下一步 现在的CUDA安装包会自动配置好PATH，等安装完成后就基本没有需要手动操作的地方了。 验证安装 命令行执行以下命令查看安装的CUDA版本： nvcc --version 然后前往C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\extras\demo_suite\(默认安装路径)，在命令行运行deviceQuery.exe和bandwidthTest.exe。若测试结果均为PASS，则CUDA环境已经成功安装。

家里有一台PVE主机打算换下来休息了，但上面还跑着2台要用的VM。PVE 7.3引入了迁移虚拟机的命令行工具，于是尝试使用qm来更方便的迁移虚拟机。 注意！源主机PVE版本需要高于7.3，否则不具备该功能 在目标主机上创建API令牌 在文件夹视图下找到“数据中心>权限>API令牌”，然后创建一个token，记得复制保留secret；然后在“数据中心>权限”处为刚刚创建的API令牌授权，需要给/路径赋予Administrator权限才能成功完成迁移。 若不授权的话，则执行迁移命令时会首先报remote: storage '<storage_name>' does not exist!，如果出现该问题的话首先检查是否忘记授权。 查看目标主机fingerprint 执行pvenode cert info，查看pve-ssl.pem的fingerprint并复制保留。 在源主机上执行迁移命令 执行命令： qm remote-migrate <source_vm_id> <target_vm_id> apitoken='Authorization: PVEAPIToken=root@pam!<token_name>=<token_secret>,fingerprint=<target_host_fingerprint>',host=<target_host>,port=<target_host_port> --target-bridge <target_bridge> --target-storage <target_storage> 静候即可。完成迁移后若需要解锁源VM，则运行qm unlock <source_vm_id>。 参考 qm(1) Framework for remote migration to cluster-external Proxmox VE hosts | Proxmox Support Forum [Tip] Proxmox VE Cross-Cluster Live-Migration - debianforum.de