install scripts for self-managed machines

This is the final report for DICE project 161, Investigate install scripts for self-managed machines.

The brief was to "Investigate potential techniques for providing install scripts, for configuring self-managed machines against DICE services."

The project was allocated one week of time.

The project had been prompted by requests from Mac users so given the limited time allocation, it was decided to concentrate on Macs.

In the end the project used three weeks of effort. Roughly speaking, one of these was spent on various technical investigations and reading; one with the user survey; and one on writing this report.


The School's Mac users were asked for their views on possible automated configuration for Macs, to set up access to various local services. The mail message and the blog post to which it refers are available online.

The survey received 21 responses, an encouraging number.

The survey asked for peoples' views on the provision of some kind of automated configuration which would help people to access DICE services from their Macs - services such as printing, AFS access, use of our VPN, and so on.

There was a lot of enthusiasm for this idea from some users.

Some people - including some who are new to Macs or who don't know (or don't want to know) much about configuring them - welcomed the idea unconditionally, giving a very positive response.

However for many people the enthusiasm was conditional on any automated configuration solution being, as it were, not so automated: that it should be applicable by the user at a time of their choosing; that the exact configuration changes made should be clear; and that the configuration changes should be easily reversible.

The survey asked for which services the respondent might find automatic configuration most useful, and supplied a list of examples. These were the most common responses:

  • Printing
  • File access / AFS (and Kerberos)
  • All of them.
  • None of them.
Some people also commented that they hadn't known of the existence of some of the listed services - suggesting the need for improved documentation, perhaps.

The "none of them" responses seemed to indicate not that those people would not use DICE services from their Macs so much as that they would prefer to configure their Macs themselves.

The survey asked whether people would prefer an automated configuration solution to be totally automated and effectively invisible to the user (as is LCFG on DICE) or controlled by the Mac's user.

Eight people were in favour of controlling it themselves and three preferred a totally automatic solution. This seems to indicate a clear preference for caution and for manually applied configuration.

A lot of the replies commented on some aspect of the documentation provided locally for Mac users. There was some praise for the clarity of the provided documents, but there were a lot of requests to keep them more up to date, with timely coverage of the latest versions of software and operating systems.

There were several requests for more, or more detailed, walk-through descriptions of how to perform configuration tasks.

The multiple mentions of documentation seemed especially notable when the survey hadn't asked about documentation. It seems to be a key issue about which people feel strongly. One response seemed to sum this up very clearly: "Personally, I'm quite happy with doing things manually. What I would appreciate most is having all the relevant documentation up to date, clearly organised, and maintained via a single point of contact."


There does not seem to be a course of action which would be welcomed by all of those Mac users surveyed. What follows is therefore a series of ideas accompanied by some speculation about how useful these might be to our Mac users.

Do nothing. Since there is no unanimity among Mac users, we could choose to take no action at this time. This would save us from the waste of developing an automation solution which had only very limited take-up. However, it would not help either those users who would heartily welcome automation or the majority of Mac users wanting improved documentation. There never is likely to be one single opinion on this matter: as long as Macs continue to attract new users (who want things to "just work") and as long as the best local configuration can be got by delving into the guts of Mac OS, there will be a difference of opinion on the best way to support Mac users.

Improve the documentation. Some of the current Mac documentation is (or was) very good, but nevertheless we could make a number of improvements:

  • Make all Mac documentation accessible from the same place, for example from a single web page, and that place well publicised to Mac users. Efforts were made in the past to gather together links to all Mac docs but they could be renewed.
  • Incorporate the work of Mac users themselves. Some of them are very keen to document their solutions to problems they've encountered and to feed back their solutions for the benefit of others. For instance, if the self-managed wiki is moribund, it might in the short term at least be revived. If necessary other solutions could be found too such as increased use of the mac-users mailing list.
  • Keep the documentation for Mac users more up to date. For instance the appearance of a new version of Mac OS or AFS should certainly prompt some kind of revision of relevant documents, if only to describe the troubles faced in trying to use that version. (With DICE Linux we have the choice of simply not deploying new OS versions until they can support important software; Macs do not give us quite such a clear choice between "supported" and "unsupported" OS versions, since new ones tend to come with a compulsory non-downgradeable installation of the latest Mac OS.) It is currently updated sporadically by a few staff more or less on a voluntary basis out of a sense of dedication and interest, as documentation for Mac users does not seem to be seen as a central part of anybody's role.
  • Whilst documentation can be unhelpful to those with no interest in or time for engaging in complicated and involved system administration on their Macs - those who in fact quite reasonably expect their Macs to "just work" - it could perhaps be improved by the incorporation of pictures, at each step of a process, showing exactly what to choose, what to click and what not to click. One respondent described himself memorably as "a double click and hope for the best kind of guy"; pictures showing a clear target for the user's clicks may make documentation less of a trial and more practically helpful for such people.
  • That said, most of our Mac users are perfectly capable of managing their Macs: what they need is technical details, and as many as possible: which driver version? Which OS revision? and so on. This is the sort of information which we have managed to supply very well from time to time.

Improvements such as these would be a solid help to most Mac users, though not all. If improved documentation was the only outcome of this exercise it might thoroughly dismay those hoping for a more automated solution.

Automation. Mac OS system admin can be automated in a variety of ways.

  • PackageMaker can be used to make software packages which bundle together applications, configuration files etc. into pkg files for installation on a user's Mac. The pkg file is a common way of distributing Mac applications and is the standard software installation format used by the University's LCFG-driven "Mac Supported Desktop" infrastructure. For most of our Mac users it has the disadvantage of being somewhat opaque: pkg files do not provide a handy list of exactly what they will do, before it's done, and do not always provide a way to back out their changes.
  • CMake can be used either natively on the Mac or as a platform-independent front end to PackageMaker. CMake is already used in the LCFG project both on Linux and on Mac OS.
  • For printer configuration (printing is one of the services of most interest), scripts could be supplied which ran CUPS commands which added configuration for a desired printer; or the CUPS commands themselves could be listed. CUPS configuration can also be done in a GUI on Macs; this might also be documented.
  • LCFG could be used to help manage the Macs. This offers the chance to pull together all the above methods into a coherent whole. Although the School of Informatics uses LCFG only to manage Linux machines, other parts of the University have successfully used it to manage Macs. At the moment about 500 Macs run the Mac Supported Desktop which is managed using LCFG. The workings of the Mac Supported Desktop were explained by Kenneth MacDonald in a talk at the 2010 LCFG Users Day (Managing Mac OS X with LCFG). The School of Informatics has until now used LCFG as an instrument of overall control of most aspects of a machine's configuration. This model has offered considerable advantages in ensuring consistency across the various aspects of a machine's and the site's configuration. In addition LCFG for Macs has until now mainly been used to manage desktops. However with the overwhelming move towards portable computers, Mac LCFG thinkers (including Kenneth MacDonald and Sean McGeever) have recently been exploring the problems and possibilities offered by lightweight LCFG use on Mac laptops. Kenneth and Sean report that so far it seems that LCFG could be used very successfully as a light-touch way of managing certain aspects of the configuration of portable Macs in the University community. This is work in progress, but when it comes to fruition it could offer us considerable advantages, such as:
  • Mac users could be given a simple mechanism by which they could choose to add, or remove, the configuration for certain items such as printers or common pieces of software. A similar user choice mechanism is offered already by IS in conjunction with its LCFG-management infrastructure.
  • The computing staff could work via LCFG, a tool suite which is very familiar to them.
  • The LCFG software tools are sophisticated enough to be able to ensure the coordinated delivery of matching versions of software and configuration, and where necessary the coordinated removal of them, taking the machine back to a different but still functional configuration. Worries about backing out changes and about version compatibility featured heavily in the caution about automation shown in the survey by experienced Mac managers.

Although the Mac platform lacks a fully featured standard package format such as rpm or deb, it does have a pkg package format which can be used to install applications. This package format is used in the installation of LCFG onto Macs. It is also used by LCFG itself to install software (software in general, not just LCFG components) onto LCFG-managed Macs.

Packages can be made using the PackageMaker component of Apple's XCode development suite. As an alternative to direct use of PackageMaker, .pkg packages can be made using CMake. This is a cross-platform utility which can use PackageMaker as a front end packaging utility on Macs. CMake is used to package LCFG components for installation on a range of platforms, including on Macs.

Thanks to the Inspace project the School of Informatics already has most of the necessary infrastructure to enable it to manage its Macs using LCFG. This uses the university's Mac Supported Desktop infrastructure. If we were to use this in Informatics we might want to adjust it to add Informatics authentication (instead of EASE) and Informatics AFS access.

When considering use on laptops, Mac LCFG has an advantage over Linux LCFG in that it is already used in a lightweight "additive" fashion, and need not conflict (so much) with configuration adjustments made by the machine's user. By contrast LCFG on Linux generally has total control over the machine's entire system configuration.

At the moment we have an IS-run Mac Supported Desktop infrastructure. Informatics has the necessary infrastructure to be able to use this. It can install software (though not remove it again), authenticate against the University's Active Directory, add "portable accounts" to the Mac (rather as DICE Linux does in Informatics) so that a user can login to different Macs with the same login details and get the same remotely stored home directory; and it also offers the capability to run a variety of LCFG components which can configure aspects of the machine's software setup. It also offers a mechanism whereby various optional configuration items can be chosen by the machine's user on a web page and applied to the machine.

Once IS has extended the Mac Supported Desktop to support laptops, the way would be open for us to try using it to perform lightweight configuration on our Macs. We might try making some of the following changes, as they seemed necessary:

  • use Informatics authentication rather than the University's Active Directory
  • cut out the IS portable accounts
  • offer AFS access
  • package up the necessary printer drivers to drive our printers, and install those
  • offer the user a choice of printers to have configured on their Mac, using the user choice mechanism on the LCFG web pages.
  • take advantage of the many software packages already existing for the IS Mac Supported Desktop

A working lightweight LCFG-controlled automated configuration for Macs should be welcomed by our less technically involved Mac users. However it would not be likely to be popular amongst more hands-on Mac managers, who would prefer better documentation. They would have to be convinced that an automated solution would be helpful to them and would do the right thing, rather than messing up their hand-crafted configurations. To bring them on board too, any solution should start off by being extremely simple - perhaps to start with installing little more than the basic components to drive the machine's use of LCFG itself together with sufficient components to install a printer driver package and add a printer configuration or two.

In the longer term, if we manage to deploy a lightweight Mac "configuration assistant" LCFG infrastructure for Macs, it might point the way to the possibility of doing something similar in the future for some versions of Linux.

-- ChrisCooke - 10 Oct 2011

Topic revision: r5 - 23 Nov 2011 - 16:41:24 - ChrisCooke
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies