-
Notifications
You must be signed in to change notification settings - Fork 1
/
READ ME FIRST.txt
143 lines (113 loc) · 6.75 KB
/
READ ME FIRST.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
You'll have to do a fair amount of manual setup work to try any of this out. The hardest part will be setting up the web server.
Somewhere in the webserver's document root you'll need a set of directories like this:
repo_root/ (this name can be changed, but the subdirectories cannot)
catalogs/
manifests/
pkgs/
pkgsinfo/
When populated, they'll look something like:
repo_root/
catalogs/
<populated by the makecatalogs tool>
manifests/
artlab_leopard
greg_neagle
production_leopard
testing_leopard
pkgs/
Firefox3.0.3.dmg
Firefox3.1b1.dmg
TextWrangler2.3.pkg.dmg
ServerAdminToold1055.dmg
adobe/
AdobePhotoshopCS3.dmg
AdobePhotoshopCS4.dmg
my_org/
MyOrgPasswordChanger.dmg
MyOrgSetupAssistant4.6.dmg
microsoft/
Office2008.dmg
Office2008SP1.dmg
Office2008v12.1.7update.dmg
other_vendor/
someflatpackage.pkg
pkgsinfo/
adobe/
AdobePhotoshopCS3
AdobePhotoshopCS4
apple/
ServerAdminTools-10.5.5
apps/
Firefox-3.0.3
Firefox-3.1b1
my_org/
MyOrgPasswordChanger
MyOrgSetupAssistant
microsoft/
Office2008-12.0.0
Office2008-12.1.0
Office2008-12.1.7
other/
someflatpackage
To serve up the manifests, you have two choices. The easiest to get started is to just create a repo_root/manifests directory and put your manifests there, then set the ManifestURL in /Library/Preferences/ManagedInstalls.plist to http:/yourwebserver/repo_root/manifests/
and set the ClientIdentifier in /Library/Preferences/ManagedInstalls.plist to the name of a manifest
so the final url is
http:/yourwebserver/repo_root/manifests/name_of_manifest
The other choice is implementing the CGI in the code/server folder in this distribution. Ask if you want more info on that.
Bootstrapping:
Put some installer items (flat packages or dmgs) in repo_root/pkgs/
Create pkginfo files. Put these in repo_root/pkgsinfo/
Create the catalogs by running makecatalogs /path/to/repo_root.
Copy the manifest example (manifest.plist) to repo_root/manifests/. Rename if you'd like.
You're done with the webserver.
On a client:
Edit ManagedInstalls.plist (from the Preferences folder in this distribution):
Change the ManagedInstallDir key to point to your desired directory. My eventual intention is /Library/Managed Installs, but for testing I've been using /Users/Shared/Managed Installs
Change the ManifestURL in /Library/Preferences/ManagedInstalls.plist to http:/yourwebserver/repo_root/manifests/
Change the ClientIdentifier to the name of the actual catalog file on the webserver (perhaps simply client_manifest.plist for now...)
Change the SoftwareRepoURL to the HTTP url to your repo_root.
Copy this file to /Library/Preferences/.
Now, from the code/client directory:
As root, run managedsoftwareupdate. You should get a copy of the client_manifest.plist in your {ManagedInstallDir}/manifests/. It should get more info on the items in the manifest by consulting the catalog(s) and decide if they need to be installed. If so, the installer items will be copied to ManagedInstallDir/Cache/
The process logs its activities at ManagedInstallDir/Logs/ManagedSoftwareUpdate.log
Finally: as root, run managedsoftwareupdate --installonly, and the items in {ManagedInstallDir}/Cache should be installed. Logs from this process go in {ManagedInstallDir}/Logs/ManagedSoftwareUpdate.log
More notes:
In the code/client directory:
Tool: managedsoftwareupdate:
This is the main client tool. It functions in a similar manner to Apple's softwareupdate command-line tool.
Client asks for a main manifest. It's retrieved. Main manifest contains some metadata and a list of managed installs. On the client, it's named client_manifest.plist, though on the server it may have any name.
managedsoftwareupdate requests a manifest via one of three values:
1) if you pass --id=arbitrarystring at the command line, it uses 'arbitrarystring' as the request:
http://webserver/repo/manifests/arbitrarystring
2) If no --id option is passed, it looks for a ClientIdentifier value in /Library/Preferences/ManagedInstalls.plist and uses that.
3) If no ClientIdentifier is available, it uses the fully-qualified hostname of the machine:
http://webserver/repo/manifests/hostname.mycompany.com
If that fails, it tries the short hostname:
http://webserver/repo/manifests/hostname
If that fails, it tries to retrieve a manifest named "site_default":
http://webserver/repo/manifests/site_default
Note that if the ManifestURL takes the form of a CGI invocation (http://webserver/cgi-bin/getmanifest?), the final URLs look like
http://webserver/cgi-bin/getmanifest?arbitrarystring
The CGI approach will open the possibility for pattern matching and more logic in the client-to-catalog mapping...
Next, the client asks for more detail on each managed install.
As we get more detail on each managed install, we may discover some dependancies, so we request more info on these as well.
We then check the items to see if they are already installed.
For items that are not installed, or have an older version, we download installer items and put them in a staging folder.
(any items previously staged that have no corresponding catalog item are removed from the staging folder - this covers the case where an item is erroneously added to a manifest and then removed before it is actually installed)
Using the dependency info and the catalog items, we build a list of items to be installed and their order. (InstallInfo.plist)
Unless the --auto option is passed, after checking for and downloading updates, managedsoftwareupdate will quit. You'll need to run it a second time with --installonly to get it to install the updates. This is a safety measure to make it less likely you'll accidently install something that requires a restart underneath a logged-in user.
Tool: Managed Software Update.app
This app will be used to notify the user that there are updates to be installed, and ask them to log out to have them installed, or notify them that they will be installed at next logout.
Users can also run this app to trigger a check for available updates; if there are no available updates (in InstallInfo.plist) when it is launched, it will run a check and return the results.
Tool: makepkginfo
Creates a managed install package info file given an Installer item:
a .pkg, a .mpkg, or a .dmg containing a .pkg or .mpkg
at the root of the mounted disk image.
You may also pass additional items that are installed by the package. These
are added to the 'installs' key of the catalog item plist and are used when
processing the catalog to check if the package needs to be installed or
reinstalled.
The generated plist is printed to STDOUT.
Usage: makepkginfo /path/to/package_or_dmg [-f /path/to/item/it/installs ...]
Tool: makecatalogs /path/to/repo
This tool scans the /path/to/repo/pkgsinfo directory and builds catalogs from the pkginfo files.