如何使 Linux Mint 18 的远程 X 访问更加可靠

如何使 Linux Mint 18 的远程 X 访问更加可靠

我有一台机器,我将其称为 RS(移除服务器),它运行的是 Linux Mint 18.3。它安装了一套桌面应用程序,包括 LibreOffice、Chrome、Eclipse 等。

我还有另一台机器,我将它称为 PC(这是我的个人计算机),我将其用作瘦客户端来访问 RS 上的应用程序和数据。我希望将应用程序和数据分开,以防止 RS 的数据最终出现在 PC 上。顺便说一句,PC 也运行 Linux Mint 的一个版本。

我在 RS 上安装了 XRDP。但我尽量避免使用它。我想让我的 PC 完成所有 GUI 操作,减少 RS 上的 RAM / CPU 使用率,这样我在其上运行的任务(例如构建代码)就可以有更多可用资源。

RS 和 PC 通过 Gb 以太网交换机连接;该交换机上几乎没有其他设备。因此,两者之间的带宽充足,无需担心安全性。

如果我告诉 PC

sudo xhost +

然后连接到 RS 并告诉它使用指向我电脑的 IP 地址的 -display 变量运行 xterm,我在电脑上得到一个 xterm 窗口,从中我可以运行应用程序(包括前面提到的 LibreOffice 和 Chrome 等 GUI 应用程序);这些应用程序在 RS 上运行,但我从 PC“驱动”它们。

我不会通过 SSH 连接来传输此信息;这只会消耗 CPU 并降低连接速度。请参阅有关交换机和相关网络隔离的前面部分。

但是,如果我花一个小时左右的时间使用 Chrome 或 LO,并且不与 xterm 交互,它就会冻结(不再接受任何输入)并最终死机。如果我让 xterm 运行某些东西(例如,跟踪长时间运行的任务的日志),它永远不会死机;只要有输出,它就会工作。

如果我花一个小时使用 LO 而忽略 Chrome,它就会冻结并最终死机。

显然,这很烦人。我会花一个多小时处理某件事,然后需要重启一些应用程序。

如果我有一段时间没有使用 gvim,当它启动时我会看到一堆关于以下内容的消息:

(gvim:6759): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Failed to connect to socket /tmp/dbus-yYgGVJw8L6: Connection refused

启动/使用/关闭 gvim 几次之后,该消息将不再出现并且 gvim 将正常工作。

听起来好像 DBUS 或其他任务由于不活动而“超时”并终止了某些任务。不过,我对 DBUS 了解不够,无法确定这是怎么回事,还是发生了其他事情。

无论发生什么,我都希望配置 RS,使得这些进程不会“超时”,而是让它们按照我的意愿运行。

如前所述,RS 已安装 XRDP。如果我运行它,然后在 PC 上使用 Remmina 访问它,应用程序永远不会“死机”,启动 gvim 时我永远不会看到 DBUS 消息。但我在 RS 上使用的 RAM/CPU 太多了,导致性能明显下降。

我愿意接受有关如何进一步排除故障的建议,并希望能够解决这个问题。

答案1

自从我发布这个问题已经过去了 18 个多月。没有人评论任何建议。我会尝试用我在此期间学到的其他知识来回答我的问题,以防其他人遇到类似的问题。

在我的例子中,远程服务器是运行在 Hyper-V 上的 Linux VM。VM 的唯一连接是动态分配 IP 地址的 VPN 客户端。

你们中的一些人此时可能会拍着自己的额头。

对于那些还没有被光线弄得眼花缭乱的人来说,PC 正在通过其 IP 地址连接到 RS(VM)。

大约每隔一小时,VPN 客户端就会重新进行身份验证并更新其 IP 地址的租约(在这种情况下,一切都会正常工作)或获取新的 IP 地址(在这种情况下,PC 会失去与 RS 的连接并且一切都会中断)。

如果我使用 RDP 连接到 XRDP,它会设法续订租约,因此 IP 地址不会改变。

在使用瘦客户端时,我曾遇到过在使用 Eclipse 的过程中杀死所有程序的情况,因此实际使用与超时不是问题。由于它不会每小时更改一次 IP 地址,因此直到查看 VPN 客户端上的日志时我才发现相关性。

使用 Gvim 时,它似乎会尝试缓存最后一个已知 IP 地址,并尝试连接到该 IP 地址上的 DBUS,而不是使用 localhost。因此,我尝试使用 Gvim 的前几次,它会尝试在旧 IP 地址上访问 DBUS,然后我收到错误消息。过了一会儿,它收到消息,连接到正确的(当前)IP 地址,错误消息消失。

以前,当我使用基于 VirtualBox 的虚拟机时,我从未遇到过此问题。但 VirtBox 虚拟机使用静态 IP 地址,并且 Windows 主机与该地址共享其 VPN 连接。由于 IP 地址从未改变,因此该系统运行可靠。

如果我能弄清楚如何让 Hyper-V 做类似的事情,这个设置就会变得可靠。

相关内容