用于 linux 的免费安全分布式 make 系统 [关闭]答案

【问题标题】：free secure distributed make system for linux [closed]用于 linux 的免费安全分布式 make 系统 [关闭]
【发布时间】：2008-12-30 02:47:00
【问题描述】：

是否有任何优秀的、与语言无关的、安全且免费的 Linux 分布式 make 系统？

背景信息：

我进行的科学实验（计算机科学实验）有时会有很大的依赖树，有时会有数千或数万个树节点。此依赖关系树位于数据文件、数据处理可执行文件和结果文件之上。

多年来，我尝试过各种技术，包括：

使用数据库滚动我自己的依赖项跟踪器并在每台工作机器上运行脚本。这可能会有点麻烦，尤其是在尝试使用非脚本语言时。
将所有处理命令放在单个 makefile 中，伪目标可以在不同的工作机器上手动“构建”。这不需要特殊工具，但手动将工作分解为大小均匀的伪目标块并在每个工作盒上正确调用“make”可能会很痛苦。
distmake：自动从单个 makefile 分发命令的执行...

我基本上是在寻找类似 distmake 的东西，但更安全。据我所知，distmake 本质上为每个工作节点留下了一个敞开的后门。

如果替代品比 distmake 更强大，那就太好了。如果你中断主 distmake 调用，它可以关闭后门服务器，但它不会正确地杀死工作节点上正在执行的进程。

说明：

我正在使用 makefile 处理数据，而不是使用 gcc 进行编译和链接。从我在文档中看到的内容来看，distcc 是一个专门用于分发 gcc 的工具。我将在共享文件系统上托管的非常大的数据文件上运行我自己的可执行文件，而不是在源文件上运行 gcc，因此 distcc 没有帮助。

工作节点是外部可见的机器，所以我希望任何工作守护进程至少与 ssh 一样安全。尽我所能在不阅读源代码的情况下判断，distmake worker 守护进程会打开一个端口，并将接受来自任何附加到它的人的命令。他们将以启动守护程序的用户身份执行命令。

【问题讨论】：

标签： makefile distributed data-processing

【解决方案1】：

依赖项很难管理，而且我不知道有任何完美的系统可以在没有大量工作的情况下完成您想要的操作。

我使用过的最接近的设置是以下设置： - 一个 Condor 队列来管理集群中的机器 - Condor DAGMAN 元调度程序提交相互依赖的作业。 DAGMAN 是 Directed Acyclic Graph MANager 的首字母缩写，其中使用有向无环图来表示你的作业之间的依赖关系。

我们已经非常成功地在我们的实验室中为迭代科学协议做到了这一点，并且效果很好，尽管对于一个非常有才华的博士后来说，让最初的实现运行起来是一次学习经历。它确实需要您设置并运行一个重要的 Condor 集群，但我假设您拥有 Condor 或类似的东西来管理您的所有机器。可能是 Sun GridEngine 有一些我不知道的类似的东西。

【讨论】：

【解决方案2】：

还有distcc，它声称可以通过SSH 运行（尽管除非distmake 非常奇怪，否则你应该能够限制对localhost 的访问并建立SSH 隧道来运行构建），以及@987654322 @。

更新： 因为目标不是分布式编译，而是恰好使用 make 作为引导程序的分布式计算，所以使用设计的工具更有意义对于像BOINC 这样的分布式计算。下面的 cmets 表示 condor 为所选平台。

【讨论】：

我会调查一下 ssh 隧道。看起来 distcc 和 icecream 仅用于编译和链接。 icecream 的主页警告它不应该在不安全的环境中使用。
那你为什么不直接写一个BOINC引擎呢？
啊，网格计算……我怎么没想到呢。我认为秃鹰可能会做我想做的事。为了未来的读者，您介意在您的回复中添加网格计算解决方案（或创建新回复）吗？

【解决方案3】：

尽管透明地与“make”集成可能会很复杂，但 GNU 并行似乎提供了一个方便的选项来跨服务器分发命令。

【讨论】：

【解决方案4】：

如果您对依赖关系很认真（即 make -jxx 在本地可以正常工作），distcc 可能就是您想要的。它非常易于使用，并且可以与几种流行的 CC 缓存一起愉快地工作。同样，正确的依赖关系是关键，尤其是在使用缓存来帮助加快重建过程时。

如果您使用 GCC 生成超出 makefile 本身的模块依赖范围的依赖项，您可能会喜欢 distcc。我一直在一个小型构建农场上使用它并取得了巨大的成功......但我的设置/树远没有你描述的那么精细。

【讨论】：

我正在处理数据文件，而不是源文件，所以我不认为 distcc 可以提供帮助。不过，我确实有适当的依赖关系（make -jxx 在本地对我来说确实很好用）。

【解决方案5】：

您可以将AT&T nmake 与coshell 程序结合使用。我不知道如何评估安全性，但 Glenn Fowler 的团队中到处都是伟大的工程师，他们做了很多非常好的事情。我会相信他们的源代码 :-) 他们最著名的工具可能是 graphviz。

【讨论】：

感谢您的想法。 coshell “与 rsh 一样安全”，这意味着像 distmake 一样，它可能很容易被欺骗。否则，它似乎是比 distmake 更好的工具。
coshell 声称能够使用ssh 以及rsh。我认为rsh 非常不安全。不知道你怎么看ssh。
我确实认为 ssh 是安全的，但是... coshell 似乎只使用 ssh 来生成 coshell 守护进程。守护进程似乎打开了自己的端口并通过它进行通信，而不是通过 ssh。因此它安全地打开了一个不安全的端口，这意味着它是不安全的。

【解决方案6】：

Makeflow 似乎也是一个很好的解决方案：http://www.cse.nd.edu/~ccl/software/makeflow/

【讨论】：