情况如下:
- 主目录位于 nfs 共享 A: /home/me
- 工作站 a、b、c、... 共享该主目录:/home/me 是指向 A:/home/me 的链接
- 所有工作站同时使用
例子:
NFS 共享 A 具有
- /主页/约翰
- /主页/安妮
工作站a有
- /home/john -> 链接到 NSF Share A /home/john
- /home/anne -> 链接到 NSF Share A /home/anne
工作站 b 具有
- /home/john -> 链接到 NSF Share A /home/john
- /home/anne -> 链接到 NSF Share A /home/anne
这往往会引发各种奇怪的问题,因为所有设置目录(.matlab、.kde、桌面等,可能还有垃圾,没有检查)都是共享的,并且同时写入/读取。此外,机器的配置可能完全不同,因此将快捷方式放在桌面上会造成很大的混乱,因为其中一半的快捷方式无法在所有机器上访问。
基本上,我正在寻找一种易于管理且毫不费力的方式来应对这种情况,类似于在 Windows 上使用漫游/本地配置文件的方式。要求如下:
- 主目录的根目录,以及我可以选择的一些其他文件夹,以及一些设置目录(如 .svn 和 .ssh),在所有机器上都必须相同
- 几乎所有其他设置目录都可以位于每个工作站本地,但也应该位于 nfs 共享上
- 理想情况下,我还会有一些应用程序允许我执行诸如“从 kde 的 Konsole 应用程序中获取所有设置,并使它们在我所有的工作站上都相同”之类的操作
答案1
我想到了一个可能的解决方案,它非常轻松,但并没有真正满足我的最后一个要求。基本思路是:让每个工作站都有自己的主目录,并创建指向应该通用的文件/目录的软链接。所有主目录仍然在 NFS 共享上,但位于不同的文件夹中。
NFS 共享:
/home/john/sharedhome/
.ssh
.svn
shareddocs
/home/anne/sharedhome/
.ssh
shareddocs
/home/john/home_A/
.kde
.vnc
.matlab
.ssh -> link to ../sharedhome/.ssh
.shareddocs -> link to ../sharedhome/.shareddocs
/home/john/home_B/
.kde
.vnc
.matlab
.ssh -> link to ../sharedhome/.ssh
.shareddocs -> link to ../sharedhome/.shareddocs
.bashrc -> link to ../sharedhome/.bashrc
etc, you get the point
工作站一:
/home/john -> linked to NFS share /home/john/home_A
/home/john/.kde -> will be NFS share /home/john/home_A/.kde
/home/john/.ssh -> will be NFS share /home/john/sharedhome/.kde
/home/anne -> linked to NFS share /home/anne/home_A
etc
工作站 b:
/home/john -> linked to NFS share /home/john/home_B
etc
不过,我还是想听听其他人的意见。另外,我还没有测试过,但似乎有效。尝试后会更新。
更新
结果非常好。必须:
- 调整服务器上的 /etc/exports 以导出所有不同的主页和一个共享主页
- 在每个工作站上,更改自动挂载程序配置以挂载该工作站的正确主目录,以及挂载共享主目录
- 为每个工作站创建必要的链接
结果在工作站上看起来像这样
/home/john -> NFS share /home/john/home_A
/home/john_shared -> NFS share /home/john/sharedhome
/home/john/sharede -> symlink to /home/john_shared
/home/john/.ssh -> symlink to ./shared/.ssh
我也会接受这个作为答案,因为没有其他人想出办法。
答案2
我会给每个用户提供他们自己单独的主目录。使用权限锁定某些应用程序的设置,并使用硬链接进行通用设置。
我认为不可能获得比这更精细的粒度。我认为,当用户尝试更改某些设置时,期望能够更改(部分)设置的应用程序可能会以意想不到的方式失败 - 因此需要仔细测试。
阅读以下内容可能会有所帮助金矿确实如此。不过他的用例更加极端。