platform-update-home/doc/working/update-policy.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.4 - (view) (download) (as text)

1 : dejan 1.1 <h1>Eclipse Update Policy Control</h1>
2 :     <p>This document describes a new Eclipse Update capability that allows large
3 :     shops with many seats of Eclipse-based products to exert control over how these
4 :     products are updated. </p>
5 :     <p>The document is related to a 3.0 plan item tracked by the following Bugzilla
6 :     entry:</p>
7 :     <p><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37702">37702</a> [plan
8 :     item] Improve organizational control over product updates</p>
9 :     <h2>1. The Problem</h2>
10 :     <p>Eclipse Update allows users to search for updates to the currently installed
11 :     features. For each installed feature, Update will use the embedded URL to
12 :     connect to the remote server and search for new versions. If there are updates,
13 :     Eclipse allows users to initiate the install procedure. After downloading,
14 :     installing and restarting the platform, new feature version is ready for use.</p>
15 :     <p>In companies with many users of the same Eclipse-based product (typically a
16 :     commercial one), several problems can arise from this model:</p>
17 :     <ol>
18 :     <li>Updates for very large products (e.g. 500+ plug-ins) can also be large.
19 :     I/T support teams may not like the idea of hundreds of developers individually
20 : dejan 1.2 downloading 500MEG updates to their individual machines. In addition to the
21 :     bandwidth hit, such a large download request may fail, leading to repeated
22 : dejan 1.1 attempts and increased developers' downtime.</li>
23 :     <li>Some companies explicitly don't want the developers downloading updates
24 :     directly from the Internet. For example, they can set up a local support team
25 :     that may not be ready to handle requests related to the version of the product
26 :     available from the provider's update site. They may want to limit updates and
27 :     fixes to the internally approved list. Ideally, they would do that by setting
28 :     up 'proxy' update sites on the LAN (behind the firewall).</li>
29 :     <li>Once updates are set in the proxy sites as above, administrators need a
30 :     way of letting users know that updates are available.</li>
31 :     </ol>
32 :     <h2>2. The Proposal</h2>
33 : dejan 1.2 <p>The proposed solution in Eclipse 3.0 consists of three new capabilities that
34 : dejan 1.1 together address all of the above problems. </p>
35 :     <h3>2.1 Support for creating local (proxy) update sites</h3>
36 :     <p>First step for a product administrator would be to set up a local Eclipse
37 :     update site on a server connected to the company's LAN (behind the firewall).
38 :     The update site would be a subset of the product's update site on the Internet
39 :     because it would contain only features and plug-ins related to the updates that
40 : dejan 1.3 the company wants applied at the moment. Technically, this site would be a
41 : dejan 1.1 regular Elipse update site with site.xml, feature and plug-in archives.</p>
42 :     <p>Administrators would construct this site in two ways:</p>
43 :     <ol>
44 : dejan 1.3 <li>Product support teams would make the zip file of the update site readily
45 : dejan 1.1 available for this particular purpose. Administrators would simply need to
46 : dejan 1.3 download the zip file from the product support web page using the tool of
47 :     their choice and unzip it in the local server. This approach is useful for
48 :     very large zip files that require modern restartable downloading managers
49 :     (those that can pick up where they left off in case of the connection
50 :     problems).</li>
51 : dejan 1.1 <li>Eclipse Update would provide a wizard that can browse remote update sites
52 :     and allow administrators to select updates and fixes to download. The behavior
53 :     would be very similar to the current update search wizard up to the install
54 :     point. At that juncture, Update would simply copy archives into the designated
55 :     local site and update site.xml instead of commencing the installation phase.
56 :     This option is fully automated and would greatly simplify administrator's task
57 :     but relies on Update network connection capabilities (improved downloading
58 :     reliability and performance is addressed in a different Update 3.0 plan item).</li>
59 :     </ol>
60 :     <h3>2.2 Common update policy control</h3>
61 :     <p>Since features have Update site URL embedded, they are unaware of the local
62 :     update sites set up by administrators. It is therefore important to provide <b>
63 :     redirection capability</b>. This and other update policy settings can be set for
64 :     a Eclipse product by creating an update policy file and configuring Update to
65 :     use that file when searching.</p>
66 :     <p>The file in question can have any name, but needs to conform to standard Java
67 :     properties syntax. The file can be set in <b>
68 :     Preferences&gt;Install/Update&gt;Automatic Updates</b> <font color="#0000FF">[as of
69 :     M1; final home may change for 3.0; in M1, the entry is called 'Address Mapping
70 :     URL'; this will also change in subsequent milestones]</font>. This entry field
71 :     is empty by default: users may set the URL of the update policy file. This file
72 :     is set up by local administrators and is shared for all the product
73 :     installations. Sharing can be achieved in two ways:</p>
74 :     <ul>
75 :     <li>If users install the product: users are told to open the preference page
76 :     and enter the provided URL</li>
77 :     <li>If administrators install the product: administrators edit the file 'plugin_customization.ini'
78 :     in the primary product feature and set the default value of the 'updatePolicyFile'
79 :     property as follows:<br>
80 :     <br>
81 :     &nbsp;&nbsp;&nbsp; <code>org.eclipse.update.core/updatePolicyFile = &lt;URL value&gt;
82 :     </code><br>
83 :     <br>
84 :     This will cause all the installation to have this file set by default.</li>
85 :     </ul>
86 :     <p>A file has been chosen for two reasons: it allows central control over the
87 :     update policy settings for an installed product, and it is also 'all or nothing'
88 :     - individual users cannot change some aspects of the policy while keeping
89 :     others.</p>
90 :     <p>The policy file can contain the following key/value pairs:</p>
91 :     <h4>url-map</h4>
92 :     <p>Syntax:</p>
93 :     <blockquote>
94 :     <pre>url-map.&lt;feature ID prefix&gt; = &lt;local URL&gt;
95 :     url-map.* = &lt;default local URL for all the features&gt;</pre>
96 :     </blockquote>
97 :     <p>This key is used to remap Update URLs embedded in feature manifests. When
98 :     searching for new updates, Eclipse search will check the update policy (if
99 :     present) and check if <b>url-map</b> for the matching feature prefix is
100 :     specified. If a match is found, the mapped URL will be used instead of the
101 :     embedded one. This way, administrators can configure Eclipse products to search
102 :     for updates in the local server behind the firewall. </p>
103 :     <p>Several url-map entries may exist in the file. The feature prefixes may be
104 :     chosen to be less or more specific. For example, to redirect all Eclipse
105 :     updates, the key would be <code>url-map.org.eclipse</code>. Similarly, it is
106 :     possible to use a complete feature ID as a prefix if redirection is required on
107 :     a per-feature basis. Finally, using '*' would set up a server URL for all the
108 :     features (a setting that should generally not be used unless total control is
109 :     needed).</p>
110 : dejan 1.4 <p>In case of multiple matches, the one with a longer pattern will be used. For
111 :     example:</p>
112 :     <blockquote>
113 :     <pre>url-map.org.eclipse = URL1
114 :     url-map.org.eclipse.jdt = URL2</pre>
115 :     </blockquote>
116 :     <p>In the case above, all Eclipse features will be updated from URL1, except
117 :     those starting with <code>org.eclipse.jdt</code> that will use URL2.</p>
118 : dejan 1.1 <h4>try-embedded</h4>
119 :     <p>Syntax:</p>
120 : dejan 1.4 <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <code>try-embedded = (true | false)
121 :     &quot;true&quot;</code></p>
122 : dejan 1.1 <p>This key sets the policy regarding features for which mapped URL was not
123 :     found. If 'true' (default), update search will default to the embedded URL if no
124 :     matching <code>url-map</code> has been found in the update policy file. Setting
125 :     'false' effectively hides the embedded update URL. The default settings is
126 :     recommended because it allows the primary product features to be updated from
127 :     the local server, while third-party (add-on) features downloaded into the
128 :     product using Eclipse Update can still by updated from the internet.</p>
129 :     <h3>2.3 Automatic discovery of updates</h3>
130 :     <p>The third part of the overall solution is covered by another plan item (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37684">Improve
131 :     Update Manager search</a>) but is mentioned here because it is an integral part
132 :     of the solution. Automatic updates will allow Eclipse to run update search on a
133 :     specified schedule (on each startup (the default), once a day, once a week
134 :     etc.). </p>
135 :     <h2>3. Conclusion </h2>
136 :     <p>Here is the complete sequence of steps that represents the solution:</p>
137 :     <ol>
138 :     <li>Administrator allocates a server on the company LAN for hosting local
139 :     product updates. Initially it contains no update sites.</li>
140 :     <li>Administrator sets up an update policy file on that server and instructs
141 :     all users to configure their products using the provided URL.</li>
142 :     <li>As the product provider ships updates and fixes on their update sites, the
143 :     administrators downloads supported updates into the local server.</li>
144 :     <li>Automatic updates executed at the scheduled frequency picks up the local
145 :     updates and informs the user</li>
146 :     <li>User chooses to install the discovered updates</li>
147 :     </ol>
148 :     <h2>4. Schedule</h2>
149 :     <p>Early implementation of the update policy (with redirection) is already in
150 :     the regular integration builds (since M1). Wizard for creating partial local
151 :     shadows of the remote update sites will appear after M2 (actual milestone not
152 :     known yet).</p>