美国铁路信号集团公司 | Linux Journal

行业新闻

作者：Lester Hightower

于 1998 年 2 月 1 日

我记得在 1995 年 9 月第一次去佛罗里达州杰克逊维尔的美国铁路信号集团公司总部时，我感到既惊讶又有些印象深刻。我感到印象深刻的是，他们的计算机网络竟然还能工作，更不用说他们实际上用它完成了相当多的工作。United 拥有我见过的最长的 10Base-2 单段线路，将大约 30 台计算机连接到两台 Novell Netware 服务器，这些服务器位于办公室一端的哈龙灭火保护室内。

主服务器是一台运行 Netware 3.12 的 Intel P90，配备 64MB 内存、三个 Adaptec 2940 SCSI 控制器、两个 1GB SCSI 硬盘和一个 20 盒式磁带、26GB Maxoptix 磁光点唱机。其中一个 1GB 磁盘通过 IPX/SPX 和 Netware NFS 导出为 “ursgpub”，这是一个共享网络文件系统，包含共享数据和一系列自定义 FoxPro 应用程序，用于跟踪项目流程和时间表等信息。

磁光点唱机的使用率约为 80%。用于 Netware 的 Corel SCSI 控制点唱机，并使用其中一个 1GB 磁盘作为其“缓存卷”。客户端需要 DOS TSR 才能让 PC 将点唱机视为连续的 26GB 文件系统。United 的 Unix CAD 工作站需要访问点唱机上的数据，PC CAD 工作站和办公 PC 也是如此。Netware NFS 不了解点唱机，因为点唱机完全由 Corel SCSI NLM 处理。为了允许 Unix CAD 工作站有限地访问该数据，必须 NFS 导出点唱机的“缓存卷”。从 Corel SCSI 下面 NFS 导出缓存卷被证明是许多问题的根源，并且一直令人头疼。

另一台服务器是一台运行 Netware 4.1 的 Intel P75，配备 32MB 内存。它的唯一职责是进行备份。ArcServe 是 United 用于备份的软件包，始终无法在 Netware 3.12 服务器上运行。因此，United 的唯一选择是购买一个 60 用户许可证的 Netware 4.1 服务器用于 ArcServe，并在每台 PC 上安装 WinAgent 客户端软件。ArcServe 似乎也从未在这台备份服务器上正常运行，几乎每晚都会因内存不足错误而崩溃，或者在客户端 PC 的 WinAgent 软件挂起时挂起。

在 1995 年 10 月中旬，我们 Progressive Computer Concepts 公司使用 Ascend Pipeline 50 通过专用 ISDN 线路将 United 的总办公室连接到 Internet。我们在配备 32MB 内存的 Intel P90、BusLogic 956C 和 1GB SCSI 磁盘上安装了 Linux 1.2.13，以处理 DNS、电子邮件、WWW 和 FTP 服务。

从我在 United 工作的这段时间来看，Netware 解决方案正在崩溃这一点变得显而易见。Netware 服务器大约每周中止一次（并且在重新启动时检查点唱机的文件系统需要数小时）。几乎每天都会以某种方式发生通过 ArcServe 进行的夜间备份失败，并且 United 的 Netware 管理员每天都会浪费数小时手动查看日志和检查磁带内容。我开始向 United 的 CEO Mike Wilson 表达我的观点，即 Linux 将是更好的解决方案。

随着时间的推移，处理 Internet 运营的一台 Linux 服务器的可靠性变得越来越清晰。我大约每 30 天会通过电子邮件向 Mike 发送一份正常运行时间报告。将 United 从 Netware 迁移到 Linux 的关键点发生在 United 的 Netware 系统管理员辞职时。现在大门为我们敞开了。

我们的去向

1996 年 6 月，我们开始了将 United 的整个运营从 Netware 迁移到 Linux 的艰巨任务。第一个被替换的是备份服务器——一个 Linux 启动盘和大约一个小时将那台小型 P75 变成了 United 的第一台名为 ursgfs2 的 Linux 文件服务器。我们立即安装了 SAMBA 和 smbfs，并开始编写备份脚本。在删除 WinAgent 并在每台 PC 上设置管理共享后，我们在当天晚上对整个楼层进行了备份到新 Linux 服务器中的 4mm 磁带驱动器；备份在每台机器上都顺利完成，没有错误。

我们购买了三个 BusLogic 958 SCSI 控制器和四个 4GB 快速宽 SCSI II Quantum Atlas 驱动器（在外部机箱中），并将它们连接到 P75 Linux 服务器 ursgfs2。现在，我们需要一种方法将大量的 CAD 文件和公司数据从连接到 Netware 服务器的 26GB 磁光点唱机中移出，当时只能通过使用 Netware 驱动程序和 TSR 程序的 DOS 机器访问。我们尝试了各种不成功的方法。

我们在 DOS 客户端上的所有尝试都因内存不足错误而失败，同时尝试从点唱机盒式磁带中 pkzip 或 xcopy 文件。Corel TSR 会在 NT 下加载，但在复制过程中会在随机点崩溃并死机。我们从未让 NT 成功复制单个盒式磁带。使用 ncpmount，我们可以从 Linux 下的 Netware 服务器挂载点唱机，但如果没有 TSR，Netware 服务器会在 60 秒内将我们踢掉。解决方案是 DOSEMU。在 ursgfs2 上安装 DOSEMU 后，我们能够运行 Corel TSR，连接到 Netware 服务器上的点唱机，然后使用 xcopy 命令直接复制到连接的 16GB 新磁盘空间。

由于 FAT（精细自动传输）文件系统效率低下，点唱机盒式磁带上的 FAT 表在盒式磁带实际装满数据之前很久就已填满。我们能够将所有点唱机数据存储到 16GB 的磁盘空间中。在所有点唱机数据传输完成后，我们从较大的服务器上删除了 Netware，将 ursgfs2 的 SCSI 卡和磁盘移动到新硬件，并将服务器重命名为 ursgfs1。不久之后又添加了第五个磁盘。

新的 Linux 文件服务器使用 SAMBA 导出到 PC，使用 NFS 导出到 Unix 工作站。该服务器有三个 4mm 磁带驱动器。我们的备份脚本使用 smbmount 挂载建筑物中的每台 PC，并使用 tar 将其存档到磁带上。很快，安装了一个八端口 Lantronix 10/100 交换机，ursgfs1 被移动到一个专用的 100MB 端口。

United 在其每个办公室都有许多 CAD 工作站，CAD 操作员每天在各种工程项目上工作。在使用 Netware/ArcServe 系统时，每晚 ArcServe 都会将 CAD 文件从每台 CAD 工作站上的特定目录层次结构复制到 Netware 服务器上的只读 CAD 文件层次结构中。United 内部的两个不同项目有可能涉及相同的 CAD 文件。当涉及的两个 CAD 操作员都不知道他们都在处理同一组文件时，这种情况尤其危险。在旧的 Netware/ArcServe 系统下，只有人类才能检测到两个 CAD 操作员同时处理同一 CAD 文件，并且通常在几天或几周后才被发现。当发现这些情况时，将不得不进行大量的 CAD 重做工作（重新 CAD 处理）。

为了解决这个问题，我们为 United 开发的下一个软件项目是编写一个自定义文件检索和存档提交程序，实际上，它将是一个修订控制系统。每天晚上，ursgfs1 会将每台 CAD 工作站的工作目录复制到临时空间。然后，文件会经过多次健全性检查，以检测重复的在建工程、验证文件修订和时间戳、文件大小等。通过所有标准的文件会被复制到只读 CAD 文件层次结构中；目前，被此过程替换的现有文件会被放入每日增量备份中。这些增量备份会保留六十天，如果需要，可以回滚任何文件的任何版本。提交文件和拒绝文件（如果有）的摘要报告会在每晚通过电子邮件发送给管理员和一个超邮件存档。该系统完全用 Perl 5 编写，自 1996 年 10 月 25 日以来一直成功运行。该系统最近已扩展到包括 United 的奥马哈办公室。

在完成备份工作后，我们开始为 United 开发自定义 Intranet 应用程序。我们用功能更全、集成度更高的 Intranet 程序取代了大多数遗留的 FoxPro LAN 应用程序。Intranet 系统，即所谓的 URSG 每日运营控制系统，完全用 Perl 5 编写。URSGDOCS 最初使用 MiniSQL 作为其后端数据库，但现在已移植到 MySQL 并已使用数月。一旦时间表录入和项目管理等所有遗留应用程序都被 Intranet 系统取代，我们就将 United 总办公室的 Internet 连接升级到 1.536MB T1。United 在旧金山、奥马哈和杰克逊维尔（制造工厂）的远程办公室立即开始通过拨号 Internet 连接使用 URSGDOCS。

图 1. URSGDOCS 的 Internet 屏幕

后来，我们在用户可能希望从 United 的每日运营控制系统检索的所有报告的底部添加了一个“传真此页”按钮。一台退役的 386DX40 配备了 32MB 内存和一个八端口 Comtrol Rocketport 板。它现在运行多个 PPP 拨入会话、各种网络嗅探器和所有 URSGDOCS 传真子系统。URSGDOCS 传真子系统是一个围绕 efax07a 软件包、虚拟 X 服务器、一些 Netscape “-remote” 命令和 Ghostscript 封装的自定义 Perl 脚本。结果是能够将任何 URSG 每日运营控制系统报告直接传真到世界任何地方的传真机，只需单击该按钮即可。

United 的奥马哈办公室发展到需要专用 T1 连接的地步。1996 年 12 月，在该办公室安装了一台 Linux 服务器。自定义文件检索和存档提交程序现在也在奥马哈运行。此外，ssh（安全外壳）用于自动将这些文件移动到杰克逊维尔的主服务器。

我们在一些 DEC Alpha UDB（通用桌面盒）上遇到了很大的优惠，最初为 United 购买了四台。Red Hat Alpha Linux 允许我们将一些服务器任务分散到这些机器上。例如，URSG 每日运营控制系统已迁移到 alpha2。Alpha4 被分配了运行旧的 26GB 磁光点唱机的角色，该点唱机已经闲置了几个月。通过围绕 Gerd Knorr 的点唱机磁盘更换器软件包封装我们自己的自定义备份脚本，我们几乎消除了 United 执行基于磁带的备份的需求。更好的是，每晚对所有可以想象到的内容进行增量备份会自动进行到中线存储。系统管理员每天早上都会收到详细的备份内容报告、由于过期而被删除的增量备份以及所有内容的磁盘使用情况状态。

桌面上的 Linux

随着 United 的持续发展和员工人数的增加，不断需要额外的桌面计算机。曾在佛罗里达州立大学校园内的超级计算机计算研究所等机构工作过，那里的四名系统管理员支持数百名 Unix 用户（很大一部分通过 X 终端），我们知道 X 终端模型适用于 United。我们开始在需要新桌面计算机的任何地方安装基于 Linux 的 X 终端。我们能够以每台 1000 美元的价格向 United 出售新的 Alpha，配备 32MB 内存、15 英寸显示器且没有硬盘。考虑到硬件、软件、设置时间和经常性维护的成本，这比部署新的 Windows 95 机器便宜得多。硬件也更便宜，而且在我们看来，即使是最初为此任务调查的专用 X 终端/网络计算机设备也更好。

Linux/Alpha X 终端通过网络启动，NFS 挂载其根文件系统和 usr 文件系统，然后在 XDMCP 服务器上打开一个 xdm（X 窗口管理器）会话。为 United 的 X 终端选择的窗口管理器是 FVWM95。收到这些 X 终端的工程师很少使用 MS Office 类型应用程序——Applixware 用于满足偶尔的需求。Netscape Navigator 用于访问 URSGDOCS 和 Internet 电子邮件。

图 2. X 终端上的 ApplixWord

X 终端模型运行良好。URSG 的所有工程师都已迁移到 X 终端。这使得 United 能够通过在布线设施和分支机构中以 X 终端和胖客户端容量重新部署老化的 386/486 级设备，从而继续延长其使用寿命。

我们的计算表明，与 United 当前使用和部署的 FAT 客户端 CAD 工作站相比，使用稍微高端的基于 Linux 的 X 终端和快速以太网可以显着节省成本。PCC 是 Bentley 将 Microstation 95 移植到 Linux 的 Beta 测试站点。该端口看起来完美无瑕，并且非常有前景；学术发布版本已经发货几个月了。但是，Bentley 尚未收到 Linux 用户认为有必要在 Linux 平台上商业支持 Microstation 的需求量。我们计划继续与 Bentley 合作，并鼓励 Microstation 的商业发布和对 Linux 的支持。