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