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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.1 - (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 :     downloading 500MEG updates to their individual machines. In addition to
21 :     bandwidth hit, such large download request may fail, leading to repeated
22 :     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 :     <p>The proposed solution in Eclipse 3.0 comprises of three new capabilities that
34 :     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 :     the company wants to apply at the moment. Technically, this site would be a
41 :     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 :     <li>Product support teams would make the zip file of the particular readily
45 :     available for this particular purpose. Administrators would simply need to
46 :     download the zip file using the tool of their choice and unzip it in the local
47 :     server. This approach is useful for very large zip files that require modern
48 :     restartable download managers (those that can pick up where they left in case
49 :     of the connection problems).</li>
50 :     <li>Eclipse Update would provide a wizard that can browse remote update sites
51 :     and allow administrators to select updates and fixes to download. The behavior
52 :     would be very similar to the current update search wizard up to the install
53 :     point. At that juncture, Update would simply copy archives into the designated
54 :     local site and update site.xml instead of commencing the installation phase.
55 :     This option is fully automated and would greatly simplify administrator's task
56 :     but relies on Update network connection capabilities (improved downloading
57 :     reliability and performance is addressed in a different Update 3.0 plan item).</li>
58 :     </ol>
59 :     <h3>2.2 Common update policy control</h3>
60 :     <p>Since features have Update site URL embedded, they are unaware of the local
61 :     update sites set up by administrators. It is therefore important to provide <b>
62 :     redirection capability</b>. This and other update policy settings can be set for
63 :     a Eclipse product by creating an update policy file and configuring Update to
64 :     use that file when searching.</p>
65 :     <p>The file in question can have any name, but needs to conform to standard Java
66 :     properties syntax. The file can be set in <b>
67 :     Preferences&gt;Install/Update&gt;Automatic Updates</b> <font color="#0000FF">[as of
68 :     M1; final home may change for 3.0; in M1, the entry is called 'Address Mapping
69 :     URL'; this will also change in subsequent milestones]</font>. This entry field
70 :     is empty by default: users may set the URL of the update policy file. This file
71 :     is set up by local administrators and is shared for all the product
72 :     installations. Sharing can be achieved in two ways:</p>
73 :     <ul>
74 :     <li>If users install the product: users are told to open the preference page
75 :     and enter the provided URL</li>
76 :     <li>If administrators install the product: administrators edit the file 'plugin_customization.ini'
77 :     in the primary product feature and set the default value of the 'updatePolicyFile'
78 :     property as follows:<br>
79 :     <br>
80 :     &nbsp;&nbsp;&nbsp; <code>org.eclipse.update.core/updatePolicyFile = &lt;URL value&gt;
81 :     </code><br>
82 :     <br>
83 :     This will cause all the installation to have this file set by default.</li>
84 :     </ul>
85 :     <p>A file has been chosen for two reasons: it allows central control over the
86 :     update policy settings for an installed product, and it is also 'all or nothing'
87 :     - individual users cannot change some aspects of the policy while keeping
88 :     others.</p>
89 :     <p>The policy file can contain the following key/value pairs:</p>
90 :     <h4>url-map</h4>
91 :     <p>Syntax:</p>
92 :     <blockquote>
93 :     <pre>url-map.&lt;feature ID prefix&gt; = &lt;local URL&gt;
94 :     url-map.* = &lt;default local URL for all the features&gt;</pre>
95 :     </blockquote>
96 :     <p>This key is used to remap Update URLs embedded in feature manifests. When
97 :     searching for new updates, Eclipse search will check the update policy (if
98 :     present) and check if <b>url-map</b> for the matching feature prefix is
99 :     specified. If a match is found, the mapped URL will be used instead of the
100 :     embedded one. This way, administrators can configure Eclipse products to search
101 :     for updates in the local server behind the firewall. </p>
102 :     <p>Several url-map entries may exist in the file. The feature prefixes may be
103 :     chosen to be less or more specific. For example, to redirect all Eclipse
104 :     updates, the key would be <code>url-map.org.eclipse</code>. Similarly, it is
105 :     possible to use a complete feature ID as a prefix if redirection is required on
106 :     a per-feature basis. Finally, using '*' would set up a server URL for all the
107 :     features (a setting that should generally not be used unless total control is
108 :     needed).</p>
109 :     <h4>try-embedded</h4>
110 :     <p>Syntax:</p>
111 :     <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; try-embedded = (true | false)
112 :     &quot;true&quot;</p>
113 :     <p>This key sets the policy regarding features for which mapped URL was not
114 :     found. If 'true' (default), update search will default to the embedded URL if no
115 :     matching <code>url-map</code> has been found in the update policy file. Setting
116 :     'false' effectively hides the embedded update URL. The default settings is
117 :     recommended because it allows the primary product features to be updated from
118 :     the local server, while third-party (add-on) features downloaded into the
119 :     product using Eclipse Update can still by updated from the internet.</p>
120 :     <h3>2.3 Automatic discovery of updates</h3>
121 :     <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
122 :     Update Manager search</a>) but is mentioned here because it is an integral part
123 :     of the solution. Automatic updates will allow Eclipse to run update search on a
124 :     specified schedule (on each startup (the default), once a day, once a week
125 :     etc.). </p>
126 :     <h2>3. Conclusion </h2>
127 :     <p>Here is the complete sequence of steps that represents the solution:</p>
128 :     <ol>
129 :     <li>Administrator allocates a server on the company LAN for hosting local
130 :     product updates. Initially it contains no update sites.</li>
131 :     <li>Administrator sets up an update policy file on that server and instructs
132 :     all users to configure their products using the provided URL.</li>
133 :     <li>As the product provider ships updates and fixes on their update sites, the
134 :     administrators downloads supported updates into the local server.</li>
135 :     <li>Automatic updates executed at the scheduled frequency picks up the local
136 :     updates and informs the user</li>
137 :     <li>User chooses to install the discovered updates</li>
138 :     </ol>
139 :     <h2>4. Schedule</h2>
140 :     <p>Early implementation of the update policy (with redirection) is already in
141 :     the regular integration builds (since M1). Wizard for creating partial local
142 :     shadows of the remote update sites will appear after M2 (actual milestone not
143 :     known yet).</p>