Linux深度学习环境搭建：16年量子计算人的排障实录

　　五月那会儿给新实验室搭深度学习环境，我原以为量子计算那套CUDA+MPI的配置够折腾了，结果在Linux安全配置上栽了三个大跟头——最离谱的是，最后解决问题的关键根本不是深度学习框架，是WAF规则里一条被遗忘的十年前漏洞补丁。那天凌晨三点，服务器日志突然刷出三百多条/var/log/secure的SSH爆破记录，IP全是东南亚肉鸡，我盯着那串103.216.x.x的地址直发懵——这IP上周刚在另一个项目组的日志里出现过，当时溯源到一半被运维叫去处理量子模拟器的内存泄漏，现在又冒出来，明显是同一拨人。

　　第一个坑出在CUDA驱动安装。按官方文档走，nvidia-smi能认出显卡，但PyTorch死活报"CUDA not available"。我查了半天，发现是SELinux把/dev/nvidia的设备文件权限锁死了——这破玩意儿在量子计算服务器上从来不开，谁想到深度学习环境默认启用了？改完权限重启，PyTorch能跑了，但日志里突然多了条"audit: type=1400 audit(...) denied"的记录，时间戳刚好是我改权限那会儿。我原以为只是SELinux的常规警告，结果第二天发现/tmp目录下多了个.ssh/known_hosts.bak的隐藏文件，文件修改时间是凌晨两点——正好是SSH爆破最凶的时候。这文件哪来的？量子计算服务器上可从没见过这种玩意儿。

　　第二个坑更邪乎。装完TensorFlow后，Jupyter Notebook能正常启动，但访问/api/kernels时总返回500错误。我查Nginx日志，发现WAF把请求拦截了，理由是"SQL注入特征匹配"。我盯着那条"SELECT FROM kernels"的请求体直乐——这明明是TensorFlow的内部API调用，跟SQL有半毛钱关系？后来翻WAF规则库，发现是十年前某次安全加固时，运维把所有包含"SELECT"的请求都默认拦截了，连注释里的"// SELECT"都不放过。我原以为这种规则早被删了，结果它就像个幽灵，安静地躺在规则库第372行，等着给深度学习环境下绊子。

文章配图，仅供参考

　　那天晚上我盯着服务器日志发呆。凌晨四点的机房里，空调嗡嗡作响，屏幕上的SSH爆破记录还在刷，但深度学习的训练任务已经跑得飞起。我突然想起上周量子模拟器崩溃时，运维小李说的一句话："这些破事儿，十有八九是安全配置搞的。"当时我还笑他太悲观，现在看，他说的太对了。安全配置就像个隐形的成本中心——你为它花的每一分钟，都不会直接体现在训练速度上，但只要漏掉一个细节，就能让你在调试环境时抓狂到想砸键盘。

　　后来我总结了下这次的经验：深度学习环境的安全配置，不能照搬量子计算的思路。量子计算服务器通常在内网，安全策略相对宽松；但深度学习环境，尤其是要跑公开数据集的，必须把安全当第一优先级——哪怕它会降低10%的性能。我现在的配置清单里，第一条就是"关闭SELinux"，第二条是"清空WAF规则库"，第三条是"禁用iptables自动规则"。小王看到后直摇头："你这配置要是被安全组看到，能被骂死。"我耸耸肩："骂就骂吧，总比训练卡在30%利用率强。"

　　对了，那串103.216.x.x的IP，我后来溯源到一半线索断了——对方用了CDN加速，真实IP藏在Cloudflare后面。我原以为能顺着日志找到攻击源头，结果还是栽在了安全配置上。现在这IP还在我的黑名单里躺着，每次看到它，我就想起那天凌晨三点，服务器日志里那三百多条SSH爆破记录，和深度学习训练任务终于跑起来的那一刻。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!