「记录」群晖DSM7 SSO客户端对接Authing服务

为了方便老师登陆各种院内系统,跟学院申请购买了Authing的统一身份认证服务。其他购买的系统都可以让开发方对接,唯一麻烦的就是群晖的DSM,只能自己来了。

最终目标是想实现每一个用户,网页登陆群晖(及任何一个学院购买的系统)的时候直接微信扫码登陆,无需输入用户名密码。群晖相较于其他系统还有一个不同点,就是SMB服务必须输入用户名密码,所以要么从Authing直接获取带密码的用户信息,要么就得让从Authing登陆的用户能自己改密码。

关于群晖DSM的SSO客户端功能的资料非常少,群晖官方也是几句就把用户打发了,而且群晖公司从销售到技术都透着一股傲然于世的气息(虽然我打心眼里觉得他家NAS做的确实很好,但这种自以为已经能拳打EMC、脚踩HPE的态度实在让人想踩死他)。找遍全网只找到这篇资料比较靠谱,而且这篇资料的最终目标和我出奇的匹配,甚至我怀疑他也是和Authing对接。鉴于现在的局域网环境,我还是把原文截图转发过来。

参考资料

虽然上面的资料和我的目标几乎完全相同,但这篇文章并没有详细描述所有在操作过程中可能遇到的坑,因此我觉得有必要记录一下我的踩坑过程。

1、群晖DSM7不支持用从SSO服务器获取的用户信息自动注册本地用户

这也是上述资料第一段所说的。详细解释就是:一个在Authing里设置好的用户,在登陆DSM之后,DSM并不会为这个用户自动创建一个本地用户,更不要提把这个本地用户和Authing的用户进行关联。这会导致一系列的麻烦,比如这个用户怎么设置DSM里共享文件夹的访问权限、这个用户怎么使用SMB服务等,这些问题很容易被忽略但又很致命(我一开始就没注意资料里第一段写了啥,都弄完才发现很重要)。

解决方法:先把DSM加入Authing的LDAP域,让DSM获取到Authing里配置好的用户、群组等信息,然后同时启用SSO客户端,并用一个唯一值进行用户关联。

2、群晖DSM本地用户和域用户冲突

当DSM本地和Authing用户池里同时有一个用户名为“张三”的用户时,会发生冲突。“张三”用户使用SSO方式进行登陆时,DSM会提示用户名密码错误。具体原因大约只有群晖工程师能解释,但我猜测是DSM没有将域用户和本地用户进行区分,导致用SSO登陆的重名用户匹配到本地用户鉴权信息上,最后鉴权失败。

解决方法:保证用户池里所有的用户名都不会出现在本地用户里。

3、配置DSM的LDAP客户端

服务器信息
LDAP信息
自定义配置文件
检测

配置LDAP客户端的最后一步是检测,会提示“不支持Samba架构”。这是由于Authing的LDAP实现问题,必须开启DSM的“启用 GIFS 明文密码验证”功能,才能通过检测。此处建议不开启,因为开启之后有安全风险。所以点详情,然后跳过。

不启用GIFS 明文密码验证

之后还会提示另一个问题,同样方式处理,跳过。最后完成所有检测之后,点击确定。

4、在Authing添加自定义应用

添加自定义应用

往下找到认证配置,修改登陆回调地址!然后再点击其他配置!

【注意】在其他配置中只修改id_token签名算法!!!其余保持不变!完成后保存

5、配置DSM的SSO客户端

到此,就完成了所有操作,可以尝试使用Authing登陆DSM了!

「记录」使用PCI设备直通技术在vSphere中部署基于Ubuntu Server 1804的GPU服务器

大约在两年前我撰写了一篇文章记录我为实验室部署GPU云的核心过程。现在给学院部署GPU云,本以为可以照着原来的文章很顺利就可以装完,结果却搞得心态爆炸,一度怀疑人生,所以很有必要再写一篇记录一下。

环境:

实体机:曙光 天阔 W780-G20
操作系统: VMware ESXi, 6.7.0, 14320388
管理平台: VMware vCenter Server Appliance, 6.7.0, 15129973
GPU:NVIDIA GP100GL [Tesla P100 PCIe 16GB] ×8

先简单说一下部署环境和上次的区别:第一是平台不再是商业大厂DELL EMC,很多文档资料缺失;第二是底层esxi和管理平台vcenter都升级到了6.7;第三是虚拟机准备安装Ubuntu Server 1804,之前的16在21年来看有点过老。最关键的是第四点:显卡质量和数量都上了一个巨大台阶,原来单台机器最多3卡(一个泰坦X,两个泰坦XP),遇到的显存最大的卡应该就是p40。当时在安装p40的时候就遇到奇怪的问题,为此还写了一篇记录文章。这次遇到的核心问题和p40那次应该是同一个,都是高级显卡显存过大,需要一些特定的底层配置参数,vmware专门有博客文章(下简称博文)进行了介绍,但是我一开始寻找解决方案的方向有很大偏差,绕了一大圈才找到。

让我一度怀疑人生的核心问题

0. 准备工作

0.1. 主机BIOS设置

根据博文内容,需要在运行虚拟GPU服务器的esxi主机的BIOS设置中查找并开启类似这样的选项:“above 4G decoding”、“memory mapped I/O above 4GB”、“PCI 64-bit resource handing above 4G”

启用BISO中的相关设定

0.2. 配置PCI设备直通

在esxi主机中配置好显卡的设备直通

0.3. 上传系统安装镜像

将ubuntu server 1804安装镜像上传到主机数据存储

1. 创建虚拟机

⚠️注意:必须在vsphere client中创建虚拟机,不可以在本地workstation创建虚拟机安装后再上传

首先按照常规方法创建虚拟机,创建后不要启动!按以下步骤进行预先配置。

1.1. 设置虚拟机引导方式为EFI

为虚拟机的“引导选项”中启用EFI

在虚拟机页面,“操作”→“编辑设置”→“虚拟机选项”→“引导选项”→“固件”,选择“EFI”。

1.2. 设置虚拟机高级配置参数

虚拟机选项中的高级选项卡

在刚才1.1的“引导选项”下方找到“高级”,点击“配置参数”右侧的“编辑配置”,进入高级参数配置窗口。

高级参数配置窗口

在窗口中点击“添加配置参数”,然后添加2条

⚠️注意:“pciPassthru.64bitMMIOSizeGB”条目的值需要根据虚拟机具体直通的显卡型号和数量进行计算后得出!

博文中提供了一种简单估算方法:GPU个数 × 一块GPU的显存大小(GB为单位),然后将结果向上取整到下一个2的整数次幂。

例如,要给这个虚拟机直通两个p100显卡,则值应为:2 × 16 = 32,向上取整到下一个2的整数次幂,得到64。但如果是直通v100显卡,64则只能直通一块,因为v100单卡显存就是32G,想要直通两块就需要改为128。

⚠️注意:与通常情况不同的是不可以添加“hypervisor.cpuid.v0 = FALSE”参数!

1.3. 修改虚拟机兼容性

选择升级虚拟机兼容性

在虚拟机页面,“操作”→“兼容性”→“升级虚拟机兼容性”,打开“配置虚拟机兼容性窗口”。

配置虚拟机兼容性窗口

将虚拟机兼容性改为:ESXi 6.7 Update 2 及更高版本

2. 安装操作系统

现在可以进行第一次开机,并按照提示安装操作系统。安装后,顺便进行基本的系统配置,例如换源、配置网络、软件包升级等。

3. 为虚拟机添加显卡直通

3.1. 启用内存预留

启用内存预留

在虚拟机页面,“操作”→“编辑设置”→“虚拟硬件”→“内存”,勾选“预留所有客户机内存(全部锁定)”。

3.2. 添加显卡设备

添加显卡设备

在虚拟机页面,“操作”→“编辑设置”→“虚拟硬件”→“添加新设备”→“PCI 设备”,然后在PCI设备选项中选择需要添加的显卡。

4. 安装NVIDIA驱动和CUDA

4.1. 检查GPU

4.2. 禁用nouveau

4.3. 安装依赖包

4.4. 安装NVIDIA驱动

默认已经下载好驱动文件

4.5. 安装CUDA

「记录」解决Ubuntu Server 18.04因Intel微码修复无法启动问题

最近在重建学院GPU云,使用原来实验室云的双层虚拟化架构。原来实验室云使用的是基于ubuntu16的GPU服务器,21年再使用16版本就有点老了,准备换成ubuntu18,但是遇到一个奇怪的问题,在此记录一下。

问题的表现形式如下:

环境:

实体机:曙光 天阔 W780-G20
操作系统: VMware ESXi, 6.7.0, 14320388
管理平台: VMware vCenter Server Appliance, 6.7.0, 15129973
虚拟机兼容性: ESXi 6.7 Update 2
虚拟机高级配置附加参数:
hypervisor.cpuid.v0 = FALSE
pciPassthru.use64bitMMIO = TRUE
虚拟机操作系统版本:Ubuntu Server 18.04.5 LTS
截止2021年1月20日,已更新所有最新包

当虚拟机CPU只给一个核心的时候,一切正常。当给2个或者更多核心的时候会出现无法启动的问题,显示如下:

虚拟机无法启动的控制台输出

经过排查发现问题触发的原因有两个:①虚拟机高级配置参数 hypervisor.cpuid.v0 = FALSE;②有2个或更多CPU核心

通过搜索找到两篇类似问题的文章:ESXi 6.7 ubuntu GPU直连踩坑记VMware ESXi 6.7.0 update2 使用 GPU Passthrough 模式的坑。第一篇文章是通过更新esxi解决的,但是第一篇文章里更新后的esxi版本与我现在使用的是同一版本,所以解决方法对我不适用。第二篇文章将问题的根源指向了intel的漏洞修补微码软件包“intel-microcode”。

通过测试发现,无法启动的核心问题就是由“intel-microcode”导致的,该软件包是intel为了修补幽灵、熔断漏洞的补丁,应该是在启动之前执行某种防护操作。我测试时首先尝试卸载该软件包,并同时卸载依赖包,结果导致部分核心包被卸载,无法启动。之后测试只卸载该软件包,不卸载依赖,结果问题解决,确定问题核心就是该软件包导致。

为了解决问题,我首先想到的是在安装vsphere过程中被提示可能受intel的漏洞影响,所以我考虑可能是虚拟化平台的宿主机没有进行漏洞修补,而ubuntu虚拟机进行了漏洞修补,出现兼容性问题。为此我查阅了vsphere的文档,确定默认状态下vsphere6.7确实是不启用漏洞修补程序的。同时,我也发现启动修补程序会导致严重的性能损失,不适合我现在的场景。

之后,我考虑既然虚拟化平台没有进行漏洞修补,那关掉ubuntu虚拟机的漏洞修补应该可以解决问题。于是我阅读了第二篇文章中提到的讨论:Intel-microcode package upgrade in ubuntu 18.04 leads to unbootable system。根据这个讨论,可以通过更改grub参数的方式禁用微码修补,但是尝试了讨论中的解决方案和关联的解决方案,发现并没有效果。最终,我决定按照讨论中的最终解决方案,更换旧版本的二进制软件包。

解决方案:

[记录]配置Docker出现的错误

  为了方便管理实验室的GPU资源,上了多层虚拟化,在部署和运维Docker节点的过程中踩了一些坑,在这记录一下,以便日后查阅。

1、Docker服务无法启动

问题定位: Docker启动的时候传入了命令行参数,同时也指定了配置文件,两个配置发生了冲突。

解决方法:

[记录]英伟达Tesla K80显卡直通出现未知错误

  实验室添置了新显卡,超微塔式服务器没地方了,只好把旧显卡换到戴尔刀片里,之后在做显卡直通的时候遇到一些莫名其妙的问题,折腾了好久才解决,在这记录一下。

环境:

实体机:DELL PowerEdge R730
操作系统: VMware ESXi, 6.5.0, 6765664
管理平台: VMware vCenter Server Appliance, 6.7.0.21000, 11726888
设备: Nvidia Tesla K80

  问题是这样的:在主机上开虚拟机,并直通其他PCI设备(usb控制器),一切正常,且虚拟机正常启动,正常识别设备。给虚拟机直通Nvidia Tesla K80,虚拟机无法开机,报未知异常,如下图:

  尝试了很多国内外常见的解决方案都无法生效。怀疑是跟显卡型号有关,最后在官方社区找到一个出现完全相同问题的讨论:Passing through Tesla k80 Issue…。下面有一个官方人员的回答是:

Re: Passing through Tesla k80 Issue…

A previous version of this post included advice to add two VMX file entries (efi.legacyBoot.enabled and efi.bootOrder) as part of the solution. These two settings should NOT be used. Instead, following the directions below.
 ——–
You should be able to pass a single GPU (that is, half of a K80) to a VM running on ESX 6 by creating an EFI-bootable VM, doing an EFI installation of your guest OS, and then adding the following to the VM’s VMX file.
pciPassthru.use64bitMMIO=”TRUE”
Trying to pass more than one of these GPUs into the same VM will currently hit a platform memory limit and the VM will fail to boot. (NOTE: This limit has been removed in ESX 6.5).
A smaller card like the K2 does not have this issue: GPGPU Blog Entry
If the above does not work for you, send me email directly at “simons at vmware dot com”. In either case, please share your experience with others on the thread.
And if you have any other questions about running HPC applications in a VMware environment, I’d be happy to hear from you directly.
If you are interested in learning more of what we’ve been doing related to HPC, you can check out our HPC entries on the VMware CTO blog site here: HPC Blog Entries
 
Josh Simons
High Performance Computing
Office of the CTO
VMware, Inc.

  关键是要添加以下高级参数:

「记录」在vSphere中基于Ubuntu Server 1604部署Docker,并安装CUDA,构建多层虚拟化深度学习开发环境

首先准备好Ubuntu Server 1604的虚拟机,只设定基本功能,不添加显卡直通等特殊功能,以便于基础环境完成后进行快照。

安装好系统后,进行ssh端口设置,apt换源,apt upgrade等基本操作,之后关机打快照。

1、 显卡直通

1.1、 添加显卡直通

勾选“预留所有客户机内存(全部锁定)”,并添加显卡PCI设备,确定修改。不在第一步直通显卡的话,之后的驱动安装可能有问题!

1.2、 修改虚拟机硬件配置参数

切换到“虚拟机硬件”选项卡。展开“高级”,修改“配置参数”。 在打开的“配置参数”对话框中,点击“添加配置参数”,填入“
hypervisor.cpuid.v0 = FALSE”
,确定修改。完成后务必再次进入“配置参数”,检查参数确实已经添加并保存!

1.3、 启动虚拟机并配置基本环境

配置网络、换源、更新软件包等

完成基本配置后建议对虚拟机生成快照!

2、 安装显卡驱动

2.1、 下载驱动

可以在 NVIDIA驱动下载 或者 Geforce显卡驱动下载 页面搜索并下载需要的驱动程序,也可以通过直接拼接资源链接:
http://cn.download.nvidia.com/XFree86/Linux-x86_64/[驱动版本号]/NVIDIA-Linux-x86_64-[驱动版本号].run,进行下载。比如我要下载430.14版本号的Linux驱动,可以直接在服务器运行以下代码:

2.2、 检查GPU

应该显示相应的PCI设备

2.3、 禁用nouveau

2.3、 安装显卡驱动

安装完驱动建议对虚拟机生成快照!

然后开机安装docker,去清华源帮助文档里找清华源安装方法。安装好之后配置docker远程管理,参考“docker 配置 TLS 认证开启远程访问”“Docker 守护进程+远程连接+安全访问+启动冲突解决办法 (完整收藏版)”。配置好docker之后关机打快照。

在ESXi中添加显卡直通,并启动。

2020年6月28日补充

2.4、安装CUDA

本处使用的CUDA安装文件是文章在19年6月初次完成时下载的,因此安装方法也是当时的安装方法。根据从英伟达官网的CUDA安装文档来看,最新的推荐安装方式似乎变成了用apt包管理器安装。但是根据最新的安装文档,我在操作过程中出现了两个问题:首先是所有的下载资源(包括软件源证书和软件包)都无法在中国大陆正常下载;另一个是安装后server系统会出现GUI界面。因此,我决定使用去年的安装包和安装方法。

安装完CUDA建议对虚拟机生成快照!

3、 安装Docker

3.1、 安装Docker

根据清华开源镜像站的帮助文档,安装Docker。

3.2、 安装nvidia-docker

安装并配置好docker建议对虚拟机生成快照!

4、 配置TLS远程管理,及Portainer接入

配置TLS远程管理是在Docker服务器(运行docker守护进程的服务器)进行配置,因此下面的$HOSTDocker服务器的IP

4.1、 修改openssl配置的CA部分

ubuntu 16.04 下 openssl 配置文件位置:/usr/lib/ssl/openssl.cnf,其他系统可参考

4.2、 生成私钥并自签证书

4.3、 颁发证书

4.4、 配置Docker使用TLS认证

4.5、 Portainer接入

如果已经添加过服务器,只更新TLS认证配置,则只需要上传相应证书:

/etc/docker/ssl/目录内的cert.pemkey.pem文件拷贝到本地,上传至Portainer。

上传证书

如果是新服务器,按照下面步骤进行添加:

配置好TLS远程管理后建议对虚拟机生成快照!

参考资料

docker 配置 TLS 认证开启远程访问

Docker 守护进程+远程连接+安全访问+启动冲突解决办法 (完整收藏版)