The document describes the goals, activities, deliverables and milestones for the development. It also gives some background on the intended locations of the files to be installed, system configuration modifications and any other pertinent information.
###Goals
-The primary goal is to allow users to install the libraries on a computer running Mac OS X without needing to build them from source. Once installed, the libraries can be used to provide authentication services to programs which use them.
+The primary goal is to allow users to install, in a single operation, everything they need to start using Moonshot. This includes:
+
+* the Moonshot GSS EAP library;
+* the SASL GS2 Library;
+* the (re-architected) Identity Selector software (currently referred to a moonshout-ui).
+
+The installer for the Identity Selector software will be delivered as part of the implementation of the architectural changes to the software (due 31st December), so the current task will deliver only the first two.
+
+We will deliver this goal incrementally, by developing sub-packages for cyrus_SASL, Moonshot EAP library and Identity selector, and combining them into a meta-package.
+
+allow users to install the libraries on a computer running Mac OS X without needing to build them from source. Once installed, the libraries can be used to provide authentication services to programs which use them.
Secondary goals are
1. Changes to files if required to allow the Moonshot GSS EAP library to be installed, as well as built, under Mac OS using autotools.
2. An installer package (or packages) that, when run, will install the necessary files to the required places in the files system. (See Outstanding questions/issues 1).
3. A compressed disk image file containing the installer package(s), which can be mounted to run the installer package. (See Outstanding questions/issues 2)
-4. Instructions and scripts for creating the installers and disk images from source. PackageMaker, (the tool provided by Apple to build installer packages - see Ref. 2) does not have a command line interface, and there do not appear to be any freely available alternatives which do, so it will probably not be possibly to automate the production of the installer package(s).
+4. Instructions and scripts for creating the installers and disk images from source. The scripts will use the [*packagemaker* tool](https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/packagemaker.1.html) to build the installer packages and the [*hdiutil* tool](https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/hdiutil.1.html#//apple_ref/doc/man/1/hdiutil) to create and to manipulate disk images.
###Activities and Milestones
1. Build and install the Cyrus SASL GS2 Library for Mac OS using autotools to prove this currently works and that it is a valid goal for the Moonshot GSS EAP library. Due Wednesday 16th November.
###Issues and questions
####To be resolved during implementation
+Q: Pete> Which files in which directories?
+> A: Pete (21-Nov-2011)> SASL GS2 library - all files in /Library/Frameworks/SASL2.framework: GSS EAP library - in gss subfolder of Kerberos Installation: Kerberos - tbd.
+
+####Resolved Issues (I think)
+Q: Pete> One package each for "Snow Leopard" and "Lion", or a single package that works for both? One disk image each for "Snow Leopard" and "Lion", or a single disk image containing both packages?
+> A: Pete (21-Nov-2011)> A single metapackage, containing sub-packages for each component. (SASL GS2, GSS EAP, Identity Selector, Kerberos)
+
Q: Sam> One of the big questions will be to what extent will you use system dependencies and to what extent will you package your own. You'll want to look over the build instructions Josh pointed you at. If you're packaging the acceptor, then all of the dependencies on the preparation page as well as everything built by the builder script apply.If you're packaging an initiator, you need Kerberos and not much else.
> A: Pete> My inclination for the Mac installer is as far as possible to use what ships with the OS - in this case Heimdal for Lion - but to include anything else in our installer - even if it *may* already be installed to support another program.
+> update 21-Nov-11 Pete> We will need to package a more recent Kerberos, both for Snow Leopard and Lion. We will build the latest stable release (1.9.2) from [MIT](from http://web.mit.edu/kerberos/dist/index.html). Moved the issue to 'Resolved'
+
Q: Sam> One of the big questions will be whether you can use the system Kerberos. My assumption is that you cannot for 10.6. You may be able
to do so for 10.7. This will be one of the big open questions we're expecting the plan to answer.
> A: Pete> Googling for 'mac os X Lion Heimdal' gives a worrying number of forum posts about problems. I'm concerned that we could end up spending time debugging 'Lion's Heimdal' which is not what you are paying us for! My inclination for the Mac installer is as far as possible to use what ships with the OS - in this case Heimdal for Lion - but to include anything else in our installer - even if it *may* already be installed to support another program. So for Lion, we should start by using Heimdal, but if we hit problems then, rather than spending a long time tracking down the problem, our first step would be to try whatever we used for Snow Leopard.
> Pete> Further information in the mailing list at https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1111&L=MOONSHOT-COMMUNITY&D=0&X=09511F3D9F0F762A88&Y=pete.fotheringham%40codethink.co.uk&P=12159 and https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1111&L=MOONSHOT-COMMUNITY&D=0&X=09511F3D9F0F762A88&Y=pete.fotheringham%40codethink.co.uk&P=13011
-Q: Pete> One package each for "Snow Leopard" and "Lion", or a single package that works for both? One disk image each for "Snow Leopard" and "Lion", or a single disk image containing both packages?
+> update 21-Nov-11 Pete>See above Moved the issue to 'Resolved'
-Q: Pete> Which files in which directories?
-
-####Resolved Issues (I think)
Q: Luke> What's the actual framework binary (that is, /Library/Frameworks/Moonshot.framework/Moonshot) going to link to -- libmoonshot-ui? That would make the most sense as mech_eap and the GS2 SASL plugin aren't directly linked against by applications. By convention, you'll need to have something there (otherwise it's not really a framework).
-> A: Pete> I was wrong - Moonshot GSS EAP is not a framework, and we won't create /Library/Frameworks/Moonshot.framework. Instead the libary will be installed to ????
+> A: Pete> I was wrong - Moonshot GSS EAP is not a framework, and we won't create /Library/Frameworks/Moonshot.framework. Instead the libary will be installed in the /gss subfolder of the Ketberos Installation
Q: Pete> New issue - do we need to do the versioning as suggested in the plan, or can we just overwrite the existing installation?
>A: Pete> The library isn';t a framework and is not linked to directly by apps, so we don't need versioning.
projects / devwiki.git / blobdiff