Mac OS X:详细解读Munki和应用

 

blog注: 本文是一个简要版本

 

详细 解 读Munki 及其 应 用

面对日益复杂的企业网络管理环境，一个小的工具，可能极大的方便系统管理员的企业日常维护需要，它可能不需要面面俱到，不一定需要付费，当然不需要美丽的外表包装，不过我们知道，需要热情和参与，包括你和我。

综述：

在系 统 管理 员 的工作中 ， 更新和 维护 客 户 系 统 是一 项 重要的任 务 ， 这 是 现 代企 业 的基本要求。不久以前每个 员 工都可以在 电脑 上自己安装 软 件 ， 这样带 来了企 业 内部管理的 混 乱 ，随着内部管理的规范， 普通 员 工被取消了任意安装 软 件的权限 ，这个任务 由管理 员 承担 ， 这样 避免了很多外来病毒造成生 产 率降低的 问题 ， 这 是系 统 管理 员为 什么要 负责 系 统 更新的原始冲 动 。

尤其是 对 于大型的企 业环 境 ， 这 种 任 务 可以 说 是一 种 挑 战 ， 之所以 这样说 ， 不 仅 因 为 客 户 系 统 的 维护 基于客 户 原因等有着 诸 多的限制 ， 而且巨大的工作站数量和各个部 门 需求的多 样 性 ， 也是不可忽 视 的因素。随着企 业对 内部人 员 的权限管理的 细 致化的要求越来越高 ， 系 统 管理 员 会承担更多的以前本可以客 户 自己完成的任 务 。比如一个重要的 软 件系 统 更新 ， 需要及 时 部署到每个相关的客 户 系 统 上 ， 由于各 种 原因 ， 可能是客 户 在出差不在可以管理范 围 之内 ， 或者是网 络 原因等 ， 管理 员 不得不 维护 一个客 户 系 统 更新的列表 ， 记录 用 户 系 统 的 现 状 ， 以及相继的 问题 解决方案等 ， 当然 现 在有各 种 审计软 件可供使用 ， 但是依然需要管理 员们 主 动 的投入相当的 热 情 ， 否 则 ， 客服可能就要接到一些莫名其妙的求救 电话 ， 使得各个部 门 之 间 的 协调 出 现 不必要的麻 烦 。 当然了 ， 如果可以投入精力把各个方面的人员都通知到 ， 那么可能 减 少抱怨 ， 但是工作量也会随之增加，而且人的记忆也是最不可靠的。不要忘了另外一点 ， 各 种 各 样 的 软 件或者系 统 更新需求会一个接着一个的出 现 ， 不会停滞 ， 否 则 系 统 管理 员 是否可以放 长 假了 呢 ？ 维护这样 一个 复 杂 的 环 境 ， 不 仅 需要 审查 系 统 ， 我 们 管理 员 更需要一 种 在符合 现 存企 业规则 的同 时 ， 尽量自 动 化的 ， 避免跟踪个 别 客 户 状 态 的 ， 或者可以描述 为让 客 户 承担起本属于自己的原始任 务 的策略。

在其它的系 统环 境中 ， 有各自不同的解决方案 ， 比如 Windows 用 户 就可以使用 SMS 和 SCCM 等 ， 不 过费 用也是不少 ， 第三方的免 费 方案也是有的。在 Mac 系 统环 境中 ， 以前的各 种 方案 ， 侧 重各有不同 ， 现 有的解决方案中比如 CasperSuite, Mac OS X Server, LANDesk Management Suite ， Apple Remote Desktop 等等都是 ，他们功能各异，许可证 费 用来 说 相比 较MS 的更能 让 人接受。不 过Mac 系 统 也有好多免 费软 件。我 们 在 这 里介 绍 的是一 种 基于客 户 ／ 服 务 器模型的一套工具 ， 这 就是 Munki 。

总 体来 说 ， 它的特点是 ： 免 费 开 源 ， 简单 有效 ， 灵 活强 劲，最主要的是它可以让没有安装软件权限的客户，根据管理员灵活设定的框架，自动或者手动地安装所需的软件 。之所以叫它是一套工具 ， 而不是解决方案 ， 主要是因 为 它的部署和 实 施的 确 需要管理 员 根据自己的网 络 环 境做相当的客 户 配置 ， 需要 变 成 ， 需要自己定制策略 ， 然后 确 定 实 施范 围 和速度等等。但是它提供了一 种 基于 软 件的可能性。而且它 还 是 处 于一 种 发 展 阶 段 ， 需要 完善和 补 充 ， 结 构 和方向有了 ， 基本的 实现 也有了 ， 这 其 实给 了我 们 极 大的 灵 活性。它的突出特色是省却了管理 员 的更新 维护 工作中和客 户 直接打交道的 费时 工作 ， 而是把 这 个任 务 部分地交 给 每个客 户 端和客 户 ， 客 户 端可以按 计 划 自 动检查 更新并安装 ， 并且不需管理 员 干 预 ； 用 户 也可以手 动 操作 ， 并且 给 客 户选择 安装的自由。

有人 问 ： 这 个和 Mac 系 统 提供的系 统 更新有什么区 别 ？ 当然有区别 ， 目前最 显 著的区 别 是 ， 它不用管理 员 在客 户 机上的 确 认 ， 就可以安装各 种 软 件、 补 丁和升 级 等等，其 实， 它的功能不只 这 一点。

谁是Munki？

它是一个开源的基于 Python开发的适用于 Mac OS X系统（当前）的软件安装／更新管理的一套工具。目前是在 Google上的一个开源项目，它的最初开发者是 Greg Neagle，创始者 Greg原来是在另外一个苹果 Google用户组的积极参与者，后来他把自己的开发项目公开了，最初的构思，受到 radmind的极大影响（ radmind是一个很早的 Mac系统部署工具，也是免费开源的），现在发展成有 20来个核心人员，人员不多，不过他们相当的活跃，使得这个项目进展得相当的稳健和迅速。这个项目也得到了 Google开发团队的认可 ， Google自己的一个 开 源项目叫 Simian就是基于这个项目之上的。

它的发音就是和猴子的英文 monkey一样 ， 所以中文就叫它猴子吧。这个名字没有特殊意义 ， 有一 种 通过训练可以为人类提供特殊服务的猴子 ， 开 发者就想到了猴子这个名字。

基本概念

在进一步了解它之前，先让我们来了解一下使用过程中我们会使用的概念。 当然，这里没有说 Mac系统部署过程中的普遍使用的概念，因为这里假定，你已经熟悉了这些基本概念。如果没有，或者参考其它资料，或者网上搜索，或者我们以后提及。

货单(manifest)：

其 实 在苹果系 统 管理里面 ， manifest 的概念 经 常被用到。很 简单 ， 货单 就是一 种 描述什么 软 件需要安装或者卸 载等软件行为规则 的文件 ，munki通过内部机制可以动态地指定某个或者某类电脑遵从某个货单定义的规则。默认的， 它存放在服 务 器的 manifest 目 录 中。

目录(catalog)：

是描述在服 务 器上提供给用 户 可以使用的 软 件目录 ，是通过munki的内部命令来自动生成的，默认的， 它存放在服 务 器的 catalogs 目 录 中。

安装项目(pkgs)：

是所有的 软 件安装包的 总 称 ，这是指具体的每个软件安装包，默认的， 它 们 存放在服 务 器的 pkgs 目 录 中。

包信息(pkgsinfo)：

它是描述一个安装包 详细 信息的文件 ，它也是使用munki内部命令自动生成，当然管理员可以编辑它的内容，以符合自己的管理环境需要。默认的， 存放在 pkgsinfo 目 录 中。

客户／ 服务模型：

猴子是基于客 户 ／ 服 务 器模型的 ， 它 对 服务器端的要求相当的 简单 ， 就是一个 Http 服 务 器，我们叫它munki服务器 ； 在客 户 端需要安装和正 确 配置munki ， 以便客 户 端能 够 正 确 地找到指定的服 务 器 ， 并 进 行正 确 的操作。

预执行代码 (preflight):

后执行代码 (postflight):

这两个概念同Mac安装包中的preflight和postflight脚本的概念是类似的，都是在执行正式步骤之前和之后需要做的事情。在munki里面他们特指在munki中的”受管软件更新”(Managed Software Update)应用程序的。

基本操作

定制pkgs：

安装格式：
猴子支持的安装程序包格式包括 ：

·      dmg 格式：他可以支持直接复制应用程序到 Applications 目录操作，这种操作是好多简单程序采用的安装方式，简便直观。

·      苹果支持的软件安装包：也就是单一文件的 pkg 包和 mpkg 包，以及包文件的 pkg 和 mpkg 安装包

·      它还特定支持 Adobe 公司的使用 Adobe's Enterprise Deployment tools 软件制作的 CS3/CS4/CS5 发布程序，以及它的更新包，还有从官方下载的 Adobe Acrobat Pro 9.x 更新程序包等。

重新包装程序：

既然它支持这么多的程序安装包格式，每种格式适应语不同的软件需求，所以面对不同的程序，很多情况下需要管理员自己重新打包，重新打包的理由很多，可能是为了满足内部安全需求，或者是程序预先注册，或者是去掉一些功能，或者是提供方便的机制，或者添加各种判断脚本等等。

至于重新打包技术，在Mac系统上是管理员的基本技能之一，相关的软件也很多，无论是命令行的还是GUI的都有，而且免费的就很好用。比如：。

重新打包是软件安装升级成败的关键第一步，可能是管理员换费时间最多的一个步骤，不仅要反复测试，软件和硬件环境，而且要考虑周到，考虑到今后的升级卸载和软件许可的管理等等因素，所以管理员可能需要具备一定的编程能力，尤其是脚本书写能力。如果这部分都需要外包，那么就需要自我提高了。

在服务器上登录造册

当我们有了需要部署到客户端的软件安装包之后，让我们来把它发布到 munki服务器上，首先把它复制到 munki服务器的 pkgs目录里面，其实在 pkgs目录里面，为了管理方便，管理员完全可以建立多层子目录，来形成一种目录式的分层结构。比如右图所示。

然后我们来把每个安装包的安装信息发布到 pkgsinfo里面，只要使用 makepkgsinfo命令，就可以轻松得到，当然有时你可能需要手动编辑一个 pkgsinfo信息，以符合你的特殊要求。

注意，一旦我们决定使用子目录来分层管理各个安装包，并相应地生成了他们的 pkgsinfo信息，请不要随便移动安装包的目录，否则，你需要重新生成各个安装包的 pkgsinfo信息。

之后，让我们来把这些信息，组合到 munki目录里面，只要使用 makecatalog命令，就可以完成这个任务。

自此，登录造册的过程已经完毕。

分组测试

这一步本来不是 munki所要求的，只不过对于一个严谨的系统管理员来说，在正式发布之前，不仅要在制作安装包的时候考虑周全，同样地，一定要在发布之前，做好实际工作环境的测试工作，不仅是测试安装包的工作，同样是测试登陆造册的过程是否完全符合当初的需求。

最终发布

完成测试，我们把安装包最终放置在 manifest里面，这样它就成为了客户端可以使用安装的了。

这个过程只是需要编辑 manifest目录里面的相应的文件，把各个软件名按照需求，比如是安装还是卸载，添加到指定的位置。

部署

munki软件：

在早期的munki软件中，它的所有部分都是包含在一个单一的安装包中的，这个不利于我们管理员的最终发布，一方面需要做一些postflight的工作，另外，可能需要对不同的发布版本，对postflight进行必要的维护。

现在，munki软件是按照功能分开的，然后统一到一个包mpkg中，这样我们可以根据需要挑选不同的安装包。

目前它包括4个部分：core,admin,app和launchd。其中只有launchd部分需要客户端重新启动来完成安装步骤。

对于服务器部分，我们始终不需要安装任何munki软件。

对于客户端，我们需要安装core,app和launchd三个部分。

对于管理员电脑，我们需要安装core和admin，对于app，你可能需要。

客户端

对于客户端，我们不仅要安装默认的munki包，还需要做客户定制。目前来说，定制包括下面的几个方面：

确定客户端所属的 manifest。

确定安装的日程，也就是编辑各个launchd文件，他们存放在目录/Library/LaunchAgents/和/Library/LaunchDeamons/里面。

生成 ManagedInstalls.plist文件，它存放在/Library/Preferences/目录里面。其中主要需要定义的是：

定义munki服务器的地址，需要把比如 SoftwareRepoURL 定义为 http://your.business.name/update；把 AppleSoftwareUpdatesOnly 定义为 False. InstallAppleSoftwareUpdates定义为 False等等。

服务器

确定服务器的位置和可用性，这需要根据你的内部的需要，比如你需要它被出差在外的人员访问吗？如果是，那么可能需要这个 http向 Internet公开，否则，就要担负 VPN的开支 。

这种更新是否很频繁，需要很多的系统资源？你可能需要多个munki服务器，一个负责承载pkgs，另外的承担pkgsinfo, manefest和catalog的服务。

安全性是否很重要？如果是，你可能需要开启和设置https服务，或者是简单的http认证服务等。

负载的考虑

服务器的负载平衡等可能是你，把munki的每个功能分布到不同的服务器，是munki内部支持的一个简单方式，其它的硬件软件负载平衡，要根据你的网络情况和需要而定。

同样的，网络负载也是一个重要的考虑因素。曾经有一个技术员，把所有的客户端设置成，在一个特定时间访问某一个特定的服务器， 而且这个功能是集成在基本系统镜像文件中的，这样造成该部门一到该时间，网络就会奇慢， 还好得益于Unix的核心，它可以被轻易的禁止。

munki提供了内置的随机延时功能，也就是，它访问munki服务器的时间一到，它会随机的延时一段时间后，再启动访问操作，这样可以比较有效的分散网络操作。不过，这也和具体的更新文件大小相关，比如一个4GB的更新包的下载可能需要10分钟，在此期间其他的访问会减慢这个更新的下载进程，如此的积累，定会影响网络其它业务的进行。

客户的更新

munki软件本身是发展很快的，所以，在客户端也需要对munki本身进行升级。升级的考虑和安装的考虑是相同的，不过是可以通过munki的机制本省进行升级的。

客户化

定制的考虑：

定制自动检查日程

定制客户的货单属性

客户操作的培训

苹果升级安装

一个简单示例

这里我们演示一个实际的简单例子。 我们在两台 Mac机器上实现，其中一台打开 http服务作为服务器，同时它也是一个受管的 munki客户端，可以访问自己系统的 http服务下载安装更新。另外一台机器是管理电脑。你也可以配置一台 Windows或者 Linux及其作为 munki服务器。

准备工作：

首先下载最新的 munki软件包，到 官方网站下载 .

在管理机上，比如 admin1，安装 munki软件。你可以根据上面部署一节的内容挑选相应的部分安装。

服务器

服务器配置

在服务器电脑的 共享偏好中，打开 web sharing。

测试是否成功，可以在任何一台机器上，在 Safari上输入该服务器的地址，比如 : http:// s456.mydomain.com/repo, 如果可以正确显示，配置就成功了。

在 F inder窗口中，转换到 /Library/WebServer/Documents目录，创建一个子目录 repo，在它里面建立另外 4个目录， pkgs,pkgsinfo,catalog,和 manifest。

确定 repo及其所有的子目录和文件的属性，你和管理员组都有 read & write权限，而其他人至少都有 read权限。

上面的步骤集成在一个命令行为 :

ROOT_DOCU="/Library/WebServer/Documents"

mkdir -p $ROOT_DOCU/repo/pkgs

mkdir -p $ROOT_DOCU/repo/pkgsinfo

mkdir -p $ROOT_DOCU/repo/catalogs

mkdir -p $ROOT_DOCU/repo/manifests

mkdir -p $ROOT_DOCU/repo/Configurations

chmod –R 774  $ROOT_DOCU/repo

我们为了维护方便，同时打开文件共享服务，并共享 /Library/WebServer/Documents/repo/目录，共享名 repo。这样我们可以方便的在管理机上进行远程管理 munki的服务器配置。

把下面的内容复制到一个文本编辑器中，比如 textedit.app，然后保存位 production的文本文件 , 注意不是 rtf格式的文件，要是纯文本文件。

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

        <key>catalogs</key>

        <array>

                <string>testing</string>

        </array>

        <key>managed_installs</key>

        <array>

                <string>Firefox</string>

                <string> ServerAdministrationSoftware</string>

        </array>

</dict>

</plist>

如果你熟悉 plist文件，那么可以看出，这个就是一个标准的文本格式的 plist文件，你当然可以用 Property List Editor编辑。

软件下载和打包

现在让我们下载两个软件，一个是 FireFox一个是 ServerAdminTools，它们分别是两种安装形式， FireFox是直接的拖拽到 Applications目录，一种是 flat的 pkg格式。对于这两个包，我们不用重新打包就可以使用。

在管理机上，确定服务器电脑的 DNS名称是正确的，比如它是 s456.mydomain.com。这个信息很重要，以后要用。

把共享的文件夹映射到管理机上 :

mount afp://s456.mydomain.com/repo

这样我们就可以通过访问 /Volumes/repo访问服务器上的 repo了。

然后把它们复制到 /Volumes/repo/pkgs/目录中。

管理工具使用（PkginfoFiles ）

在管理机上，执行下面命令来生成 pkgsinfo文件 :

/usr/local/munki/makepkginfo /Volumes/repo/pkgs/firefox5.dmg > /Volumes/repo/pkgsinfo/firefox5.pkginfo

/usr/local/munki/makepkginfo /Volumes/repo/pkgs/ServerAdministrationSoftware.pkg > /Volumes/repo/pkgsinfo/ ServerAdministrationSoftware.pkginfo

如果没有错误，继续执行下面命令 :

/usr/local/munki/makecatalog /Volumes/repo/

客户端配置

软件安装

安装 munki软件在客户端上，也就是 s456机器上。需要重新启动。

配置

执行下面的命令来进行基本的配置：

defaults write /Library/Preferences/ManagedInstalls ClientIdentifier –string “testing”

defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL –string “http:// s456.mydomain.com/repo”

defaults write /Library/Preferences/ManagedInstalls AppleSoftwareUpdatesOnly –bool false

defaults write /Library/Preferences/ManagedInstalls InstallAppleSoftwareUpdates –bool false

测试

如果你希望等待，那么可以等待客户机自动检查更新，自动下载，自动安装。不过为了测试我们来手动安装。

在客户机上的 /Applications/Utilities目录中，安装了一个 Managed Software Update.app程序，它是一个类似苹果 Software Update程序的软件，可供客户手动安装受管软件的安装。

执行它，如果配置正确，那么你可以看见 FireFox和 ServerAdministrationSoftware两个软件在列表中，只要是按照提示安装就可以了。

完成了！

颗粒化管理

基本意图

如何实现

安全

目前来 说 ， 它可以提供了基本的安全保 护 ， 比如使用 http简单认证 ， 或者是 https认证 ，

真实示例简述

今后发展

集成更多功能 ： 审计 功能

支持更多的 设备 ： iPhone, iPod touch, iPad, 其它 设备 ， Andorid 等 .

支持更多的系 统 ： Windows, Linux 等

原文链接： http://blog.csdn.net/afatgoat/article/details/6527545

转载于:https://my.oschina.net/junwong/blog/46401