discussions
discussions copied to clipboard
ustclug
内网服务器远程挂载FTP家目录
功能：通过NFS在各个服务器上远程挂载LUG FTP的家目录。 意义：在所有服务器上共享同一个家目录，避免配置迁移。同时，也新增了一个内外网互通数据的方式，方便传递数据。 方案：autofs+NFSv4
在vm-nfs上部署了一个样例，登录vm-nfs即可尝试： ssh vm-nfs.s.ustclug.org
大家觉得如何？
一来，内网还是比较稳定的；二来，如果内网挂了，LDAP也就用不了了，即便没有NFS，普通用户也无法登录。这时应该使用root用户连接，解决内网故障。root用户并不受NFS影响。
On 15 Jul 2017, at 19:35, zhsj [email protected] wrote:
还是比较危险的，要是nfs挂了，登录都困难了。。让用户自己选择吧，现在就可以直接sftp挂的吧？
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ustclug/discussions/issues/155#issuecomment-315528415, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMs9Ajy2CFpdyh4_3sZbqMKXkv7Ko-rks5sOKQMgaJpZM4OY_Ox.
我查了一下：
autofs is a program for automatically mounting directories on an as-needed basis. Auto-mounts are mounted only as they are accessed, and are unmounted after a period of inactivity.
也就是说如果nfs挂了，至少不会导致系统无法启动，至于是否会导致登陆困难，我就不清楚了。不知道如果nfs挂了，访问挂载的目录时（shell启动时肯定会读取$HOME的），是会卡住，还是会立即返回一个错误。不知道 @gaoyifan 有没有测试过。
另外，根据Arch的wiki，systemd也支持类似autofs的功能：https://wiki.archlinux.org/index.php/Fstab#Automount_with_systemd
那就是说，用密码应该是能登陆的啰（如果允许用密码登陆的话）？
此外，返回 Authentication failed 是立刻返回的，还是会等一会儿？如果是立刻返回的话，说明nfs卡住之后，autofs会立刻返回错误，而不是等超时。
一来，内网还是比较稳定的；二来，如果内网挂了，LDAP也就用不了了，即便没有NFS，普通用户也无法登录。这时应该使用root用户连接，解决内网故障。root用户并不受NFS影响。
不光是网络，还有 nfs 本身，比如 io 负载高了，响应慢而导致超时等等。默认家目录挂在 NFS 太过危险了。
把所有出现的异常交由 root 用户，而 root 密钥又基本只有一个人掌握，这样带来的结果只能是解决问题十分漫长。
LDAP 现在这个问题也是要考虑，为啥缓存没了，导致现在 LDAP 一连不上（可能只是暂时的网络抖动）就所有人无法登陆了。。。
我觉得比较好的是，用户自己选择怎么挂 ftp 目录。比如默认 shell 读的环境是本地的，然后开 tmux 的时候，启动的 shell 读远程的配置；或者 ftp 默认挂在另外一处，有个快捷的脚本在需要的时候建软链接过去；等等。
@StephenPCG 会等待超时，且不会尝试密码。
@zhsj
不光是网络，还有 nfs 本身，比如 io 负载高了，响应慢而导致超时等等。默认家目录挂在 NFS 太过危险了。
NFS作为一个历史悠久的内核模块，可靠性还是有保障的。 LUG FTP目前已迁移到图书馆新提供的磁盘整列上，这个阵列性能相当好，对于顺序IO而言，即便千兆网卡用满，IO utils也只有不到20%。随机IO的性能也还不错。IO负载高导致超时的情形其实很难发生。 实际上，整个环节中最有可能出问题的就是网络了。
把所有出现的异常交由 root 用户，而 root 密钥又基本只有一个人掌握，这样带来的结果只能是解决问题十分漫长。
目前我们的服务器保留了多种应急维护的手段，对于物理机而言，在内网故障的情况下，可以使用ssh以root用户身份登录维护，也可以用远程管理卡直接访问显示器、键盘、鼠标；对于虚拟机而言，则可以直接在虚拟机管理平台中操作虚拟机。虚拟机平台可以直接在校园网中访问，不依赖LUG内网。这些应急维护措施，正是为解决如内网故障这种特殊故障而存在的。 我觉得这个问题的解决方法是：对于有热情、有维护能力的童鞋，都应该给予对应的权限（如SSH签名允许root登录，虚拟化平台权限），而不是将权限集中在极少数人手中。虽然集权提升了安全性，但也限制了大家的成长。我们毕竟是一个社团，维护服务器只是手段，增强技术实力才是目的。我比较倾向于牺牲一部分安全性，换取大多数人技术实力的提升。
LDAP 现在这个问题也是要考虑，为啥缓存没了，导致现在 LDAP 一连不上（可能只是暂时的网络抖动）就所有人无法登陆了。。。
早期，由于网络不稳定，LDAP可靠性不佳。更令人沮丧的是，nscd不仅会缓存成功的结果，也会缓存失败的结果，并且我没找到单独设置负向缓存的选项。LDAP查询失败后，nscd会将失败结果缓存较长时间，造成网络恢复后也无法登陆的窘境。因此索性关掉了nscd。 https://github.com/ustclug/discussions/issues/88 自从修复了这个问题之后，我感觉内网已经比较稳定了。近半年以来我还没有遇到过由于LDAP的原因导致的登录失败。
我觉得比较好的是，用户自己选择怎么挂 ftp 目录。比如默认 shell 读的环境是本地的，然后开 tmux 的时候，启动的 shell 读远程的配置；或者 ftp 默认挂在另外一处，有个快捷的脚本在需要的时候建软链接过去；等等。
这实际上就是便利性的平衡啦。 我之所以萌生直接挂载家目录的想法，是因为看到 @knight42 和 @Alkaid-Benetnash 用SaltStack在所有服务器上分发他们的oh-my-zsh配置🙈。假如能够在所有服务器上共享家目录，不仅能够实现数据互通，而且所有服务器上的shell配置、vim配置、命令历史都能无缝同步。也就不需要salt这种workaround了。
LUG的多项服务以及管理员绝大多数维护操作都依赖于稳定的内网，这已经发展成为了一种常态。我更希望小伙伴们能考虑如何增强内网的稳定性、如何改进架构（包括推翻整个架构，重新来过）、如何在稳定的内网之上搭建上层应用， 而不是将关注点集中在“无法登陆”这种低概率的事件上，这就有些因噎废食了。