Do them on the weekend and claim the overtime ;-)<br><br><div class="gmail_quote">2009/7/28 Rainer Meier <span dir="ltr"><<a href="mailto:r.meier@wpkg.org">r.meier@wpkg.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<div class="im"><br>
Tomasz Chmielewski wrote:<br>
> I did some experiments with multicasting (copy the file to the local<br>
> machine using multicast), but it didn't work reliably and setup was<br>
> complicated.<br>
><br>
> In reality, it perhaps makes sense to split the configuration into<br>
> logical groups (rooms, floors etc.) - and deploy one after another<br>
> (Monday - rooms 1xx, 2xx, Tuesday - 3xx etc.).<br>
> This also prevents you from simple mistakes to some extent: if you made<br>
> a package which doesn't start (i.e. uninstalls the old version, but<br>
> doesn't install a new version, leaving you with no software installed),<br>
> not all users will be affected.<br>
<br>
</div>I fully agree to the proposal and would like to add another possibility. If you<br>
frequently need to deploy this amount of data it might even make sense to add<br>
more servers to deploy the software. So groups of clients could access their own<br>
local WPKG server. In easiest case even a workgroup NAS in an office could serve<br>
local clients while WPKG updates are pushed using rsync or similar.<br>
<br>
However I don't recommend this approach for large enterprises. It's more<br>
suitable for small or medium sized companies with multiple locations where<br>
remote traffic to the central server should be avoided.<br>
<br>
So if your 1500 clients are on the same site as the server adding multiple<br>
profiles to segment the roll-out looks suitable. The easiest way to achieve this<br>
might be to duplicate your WPKG installation into multiple directories and<br>
having each group of clients pointing to another installation. Just creating<br>
multiple profiles is usually not enough since a package can by definition exist<br>
only once in the package tree - so as soon as you update it all clients<br>
referring to this package (no matter from which profile) will trigger an update.<br>
<br>
<br>
Alternatively deploying more server power (load-balancers etc.) seems to me it<br>
could be overkill since upgrading large packages like OOo is not an every-day task.<br>
<br>
Another possibility which comes to my mind is: Why not running the upgrade<br>
manually to spread the load?<br>
Larger enterprises (like yours seem to be) quite often use hardware which<br>
supports WoL (Wake On LAN). So just wake up the machines at midnight and let<br>
them deploy the software. If you can't reach a few of them it does not matter a<br>
lot because the remaining ones would not overload your server in the morning.<br>
On clients which are already running you might remotely run the WPKG service to<br>
initiate the deployment.<br>
<br>
Hopefully this gives some hints.<br>
<br>
<br>
br,<br>
<font color="#888888">Rainer<br>
</font><div><div></div><div class="h5">-------------------------------------------------------------------------<br>
wpkg-users mailing list archives >> <a href="http://lists.wpkg.org/pipermail/wpkg-users/" target="_blank">http://lists.wpkg.org/pipermail/wpkg-users/</a><br>
_______________________________________________<br>
wpkg-users mailing list<br>
<a href="mailto:wpkg-users@lists.wpkg.org">wpkg-users@lists.wpkg.org</a><br>
<a href="http://lists.wpkg.org/mailman/listinfo/wpkg-users" target="_blank">http://lists.wpkg.org/mailman/listinfo/wpkg-users</a><br>
</div></div></blockquote></div><br>