谁使用 Mac OS X Server？为什么？

Question 1

编辑，因为这篇文章仍然偶尔会收到投票：以下所有观点现在都无关紧要。由于没有真正的 Mac 服务器硬件，服务器软件只是客户端 OS X 的廉价附加组件，可用性和功能受到极大限制，因此较新的 OS X 服务器版本 (10.7+) 无法在小型工作组之外合理使用，最好是在只有 Mac 的商店中使用。

我本来要写一篇没完没了地论述利弊的文章，不过我们还是长话短说吧。

如果您在网络中使用 Mac 客户端，MacOS Server 可提供巨大优势。它允许极其轻松地为 Mac 客户端创建与 Win 组策略相当的功能，这比在 Windows 服务器上为 Win 客户端执行相同操作要容易得多。
当然，它还完全支持所有小型 Mac 客户端特性，如资源分支、查找器属性等，如果您使用 Win 或 Linux 服务器，这些特性都有可能成为真正的麻烦。告诉您的用户您不支持这些特性可能是可行的，但这也可能会破坏某些应用程序。
根据我的经验，一般管理比任何 Linux 系统和 Windows 都容易得多，至少对于较小的团体来说是这样。扩展是另一回事，但这需要对任何平台都有详细的了解。至少在要求简单的情况下，对于只使用 Mac 的商店来说，不需要专业管理员的承诺比任何其他平台都更现实。
即使您计划在没有专业管理员的情况下在 10 到 20 个用户环境中运行仅 Win 客户端或混合 Win/Mac 环境与 Linux 服务器和 Samba，我还是建议在许多情况下使用 MacoS 服务器，因为它将所有这些隐含的复杂性隐藏在一个非常易于使用的 GUI 后面。
虽然这不是问题的主题，即使初次购买时 Mac 比 Windows 客户端更贵，但如果用户不再考虑品牌和声誉，而是开始了解真正的差异和优缺点，而不仅仅是标志和或多或少花哨的 GUI，那么 Mac 在许多环境中的 TCO 要低得多。

尽管如此，MacOS Server 当然也有一些缺点。

首先，虽然这确实是可能的，但它并不适合企业规模，而且这样做需要对系统有深入的了解。
此外，尽管 Apple 使用了许多标准开源软件包来创建系统，但他们经常决定做一些与其他公司略有不同的事情，有时甚至毫无理由。这可能需要解决一些问题（不将密码存储在 LDAP 数据库中就是一个典型的例子）。
如果您熟悉 Linux，拥有的 Win/Linux 客户端比 Mac 客户端多，并且可以忍受 Mac 端的一些限制，那么 Linux 服务器确实会更便宜。
将 MacOS 服务器集成到更大的环境中有时会非常困难。
通常，软件/硬件包未经过 MacOS 认证，因此在需要时无法获得支持。我目前在规划 SAN 时就遇到了这种情况。

总而言之，我只能建议真正了解不同架构提供的功能以及您的要求，并据此做出决定。如果老板只想在网络中添加几台 Mac，而没有考虑后果，只是为了赶时髦，拥有一台 Mac，那么他和那些因为“Apple 只适合粉丝”而回避 Apple 一切的管理员一样愚蠢，他们对这个平台一无所知。

Answer

编辑，因为这篇文章仍然偶尔会收到投票：以下所有观点现在都无关紧要。由于没有真正的 Mac 服务器硬件，服务器软件只是客户端 OS X 的廉价附加组件，可用性和功能受到极大限制，因此较新的 OS X 服务器版本 (10.7+) 无法在小型工作组之外合理使用，最好是在只有 Mac 的商店中使用。

我本来要写一篇没完没了地论述利弊的文章，不过我们还是长话短说吧。

如果您在网络中使用 Mac 客户端，MacOS Server 可提供巨大优势。它允许极其轻松地为 Mac 客户端创建与 Win 组策略相当的功能，这比在 Windows 服务器上为 Win 客户端执行相同操作要容易得多。
当然，它还完全支持所有小型 Mac 客户端特性，如资源分支、查找器属性等，如果您使用 Win 或 Linux 服务器，这些特性都有可能成为真正的麻烦。告诉您的用户您不支持这些特性可能是可行的，但这也可能会破坏某些应用程序。
根据我的经验，一般管理比任何 Linux 系统和 Windows 都容易得多，至少对于较小的团体来说是这样。扩展是另一回事，但这需要对任何平台都有详细的了解。至少在要求简单的情况下，对于只使用 Mac 的商店来说，不需要专业管理员的承诺比任何其他平台都更现实。
即使您计划在没有专业管理员的情况下在 10 到 20 个用户环境中运行仅 Win 客户端或混合 Win/Mac 环境与 Linux 服务器和 Samba，我还是建议在许多情况下使用 MacoS 服务器，因为它将所有这些隐含的复杂性隐藏在一个非常易于使用的 GUI 后面。
虽然这不是问题的主题，即使初次购买时 Mac 比 Windows 客户端更贵，但如果用户不再考虑品牌和声誉，而是开始了解真正的差异和优缺点，而不仅仅是标志和或多或少花哨的 GUI，那么 Mac 在许多环境中的 TCO 要低得多。

尽管如此，MacOS Server 当然也有一些缺点。

首先，虽然这确实是可能的，但它并不适合企业规模，而且这样做需要对系统有深入的了解。
此外，尽管 Apple 使用了许多标准开源软件包来创建系统，但他们经常决定做一些与其他公司略有不同的事情，有时甚至毫无理由。这可能需要解决一些问题（不将密码存储在 LDAP 数据库中就是一个典型的例子）。
如果您熟悉 Linux，拥有的 Win/Linux 客户端比 Mac 客户端多，并且可以忍受 Mac 端的一些限制，那么 Linux 服务器确实会更便宜。
将 MacOS 服务器集成到更大的环境中有时会非常困难。
通常，软件/硬件包未经过 MacOS 认证，因此在需要时无法获得支持。我目前在规划 SAN 时就遇到了这种情况。

总而言之，我只能建议真正了解不同架构提供的功能以及您的要求，并据此做出决定。如果老板只想在网络中添加几台 Mac，而没有考虑后果，只是为了赶时髦，拥有一台 Mac，那么他和那些因为“Apple 只适合粉丝”而回避 Apple 一切的管理员一样愚蠢，他们对这个平台一无所知。

Question 2

我在一所大学工作，我们用它来运行 Deploy Studio，以便为我们的 Mac 实验室制作映像，以及用于网络启动，后者与 Deploy Studio 密切合作。它也是我们的 Open Directory 服务器，以便 Mac 可以绑定到 AD 和 OD。AD 将进行凭证验证并颁发 Kerberos 票证，而 OD 则控制那些组策略不适用的麻烦的 Mac 专用设置。

Answer

我在一所大学工作，我们用它来运行 Deploy Studio，以便为我们的 Mac 实验室制作映像，以及用于网络启动，后者与 Deploy Studio 密切合作。它也是我们的 Open Directory 服务器，以便 Mac 可以绑定到 AD 和 OD。AD 将进行凭证验证并颁发 Kerberos 票证，而 OD 则控制那些组策略不适用的麻烦的 Mac 专用设置。

Question 3

添加有关 Marie 在评论中提出的群件功能的答案：

这仍然是一个非常新的发展，老实说，我真的不明白苹果的发展方向。

首先，我必须承认我还没有真正使用过 MacOS iCal 服务器，而且作为用户和管理员，我对其他群件解决方案的经验也非常有限。不过，我玩了一下之后的印象是：

邮件由 Postfix/Cyrus 在 10.5 上提供（10.6 上切换到 Postfix/Dovecot），SquirrelMail 作为 Web 界面。使用标准管理工具，您所能做的就是为用户添加邮件帐户，并决定是否将其转发到另一个地址。除此之外的一切都需要手工操作，例如别名、筛选过滤、共享邮箱和 IMAP 的文件夹 ACL。
Mail.app 和日历之间只有一层非常薄的集成，基本上仅限于发送邀请。Squirrelmail 完全独立，根本没有与系统进行任何集成，而且用户界面也非常过时和笨重。
日历功能也非常基础。系统提供了一些标准功能，如服务器上其他用户的邀请、受邀者和资源的空闲/忙碌检查等。此功能提供两个不同的级别，分别为用户和工作组。对于用户日历，与 iCal 桌面应用程序的集成非常紧密，但对于组来说，添加日历功能非常困难且完全不直观，并且仅限于只读（我不确定它是否在空闲/忙碌安排中使用）。日历共享和委派是可能的，但具有相当广泛的权限方案。
网络界面使用起来相当不错（很多它是一种比 Squirrelmail 更好的邮件服务，提供基本的日历、博客和 wiki 功能，同样为用户和工作组提供两个不同的级别，且两个级别之间几乎没有整合。
联系人仅由桌面地址簿应用程序处理，用户之间完全不共享。10.6 将提供地址簿服务器，但据我了解，这是为了在不同的计算机之间同步地址簿，如 iSync，而不是为了共享。地址簿可以读取 LDAP 树，但无法修改其中的条目。

总而言之，OS X Server 中的群件是松散集成的组件的集合。它提供的功能并不多，但大多数都易于使用和管理，对于 Apple 认为的典型服务器客户（小型创意机构等）来说可能已经足够了。如果您想要更多，那么每个主要的群件套件（Exchange、Zimbra、OX 等）都会让 Apple 的解决方案相形见绌。

Answer