blog注: 本文是一个简要版本   **详细****解****读Munki****及其****应****用****** 面对日益复杂的企业网络管理环境，一个小的工具，可能极大的方便系统管理员的企业日常维护需要，它可能不需要面面俱到，不一定需要付费，当然不需要美丽的外表包装，不过我们知道，需要热情和参与，包括你和我。 ### 综述： 在系统管理员的工作中，更新和维护客户系统是一项重要的任务，这是现代企业的基本要求。不久以前每个员工都可以在电脑上自己安装软件，这样带来了企业内部管理的混乱，随着内部管理的规范，普通员工被取消了任意安装软件的权限，这个任务由管理员承担，这样避免了很多外来病毒造成生产率降低的问题，这是系统管理员为什么要负责系统更新的原始冲动。 尤其是对于大型的企业环境，这种任务可以说是一种挑战，之所以这样说，不仅因为客户系统的维护基于客户原因等有着诸多的限制，而且巨大的工作站数量和各个部门需求的多样性，也是不可忽视的因素。随着企业对内部人员的权限管理的细致化的要求越来越高，系统管理员会承担更多的以前本可以客户自己完成的任务。比如一个重要的软件系统更新，需要及时部署到每个相关的客户系统上，由于各种原因，可能是客户在出差不在可以管理范围之内，或者是网络原因等，管理员不得不维护一个客户系统更新的列表，记录用户系统的现状，以及相继的问题解决方案等，当然现在有各种审计软件可供使用，但是依然需要管理员们主动的投入相当的热情，否则，客服可能就要接到一些莫名其妙的求救电话，使得各个部门之间的协调出现不必要的麻烦。当然了，如果可以投入精力把各个方面的人员都通知到，那么可能减少抱怨，但是工作量也会随之增加，而且人的记忆也是最不可靠的。不要忘了另外一点，各种各样的软件或者系统更新需求会一个接着一个的出现，不会停滞，否则系统管理员是否可以放长假了呢？维护这样一个复杂的环境，不仅需要审查系统，我们管理员更需要一种在符合现存企业规则的同时，尽量自动化的，避免跟踪个别客户状态的，或者可以描述为让客户承担起本属于自己的原始任务的策略。 在其它的系统环境中，有各自不同的解决方案，比如Windows用户就可以使用SMS和SCCM等，不过费用也是不少，第三方的免费方案也是有的。在 Mac系统环境中，以前的各种方案，侧重各有不同，现有的解决方案中比如CasperSuite, MacOS X Server, LANDesk Management Suite，Apple RemoteDesktop等等都是，他们功能各异，许可证费用来说相比较MS的更能让人接受。不过Mac系统也有好多免费软件。我们在这里介绍的是一种基于客户／服务器模型的一套工具， 这就是Munki。 总体来说，它的特点是：免费开源，简单有效，灵活强劲，最主要的是它可以让没有安装软件权限的客户，根据管理员灵活设定的框架，自动或者手动地安装所需的软件。之所以叫它是一套工具，而不是解决方案，主要是因为它的部署和实施的确需要管理员根据自己的网络 环境做相当的客户配置，需要变成，需要自己定制策略，然后确定实施范围和速度等等。但是它提供了一种基于软件的可能性。而且它还是处于一种发展阶段，需要完善和补充，结构和方向有了，基本的实现也有了，这其实给了我们极大的灵活性。它的突出特色是省却了管理员的更新维护工作中和客户直接打交道的费时工作，而是把这个任务部分地交给每个客户端和客户，客户端可以按计划自动检查更新并安装，并且不需管理员干预；用户也可以手动操作，并且给客户选择安装的自由。 有人问：这个和Mac系统提供的系统更新有什么区别？当然有区别，目前最显著的区别是，它不用管理员在客户机上的确认，就可以安装各种软件、补丁和升级等等，其实，它的功能不只这一点。 ### 谁是Munki？ 它是一个开源的基于Python开发的适用于MacOS X系统（当前）的软件安装／更新管理的一套工具。目前是在Google上的一个开源项目，它的最初开发者是GregNeagle，创始者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中的”受管软件更新”(ManagedSoftware 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软件包，到[官方网站下载](http://code.google.com/p/munki/downloads/list). 在管理机上，比如admin1，安装munki软件。你可以根据上面部署一节的内容挑选相应的部分安装。 ### 服务器 #### 服务器配置 在服务器电脑的共享偏好中，打开web sharing。 测试是否成功，可以在任何一台机器上，在Safari上输入该服务器的地址，比如: http://* s456.mydomain.com/repo,*如果可以正确显示，配置就成功了。 在Finder窗口中，转换到/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 "-//AppleComputer//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](http://code.google.com/p/munki/wiki/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/ManagedInstallsClientIdentifier –string “testing”* *defaults write /Library/Preferences/ManagedInstallsSoftwareRepoURL –string “http:// s456.mydomain.com/repo”* *defaults write /Library/Preferences/ManagedInstallsAppleSoftwareUpdatesOnly –bool false* *defaults write /Library/Preferences/ManagedInstallsInstallAppleSoftwareUpdates –bool false* ### 测试 如果你希望等待，那么可以等待客户机自动检查更新，自动下载，自动安装。不过为了测试我们来手动安装。 在客户机上的/Applications/Utilities目录中，安装了一个ManagedSoftware Update.app程序，它是一个类似苹果Software Update程序的软件，可供客户手动安装受管软件的安装。 执行它，如果配置正确，那么你可以看见FireFox和**ServerAdministrationSoftware两个软件在列表中，只要是按照提示安装就可以了。 完成了！ ### 颗粒化管理 ### 基本意图 ### 如何实现 ### 安全 **目前来****说****，****它可以提供了基本的安全保****护****，****比如使用****http简单认证****，****或者是****https认证****，****** ******** ### 真实示例简述 ### 今后发展 **集成更多功能****：****审计****功能****** **支持更多的****设备****：****iPhone, iPod touch, iPad,****其它****设备****，****Andorid****等****.****** **支持更多的系****统****：****Windows, Linux****等******