Do them on the weekend and claim the overtime ;-) 2009/7/28 Rainer Meier <r.meier at wpkg.org> > 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 at lists.wpkg.org > http://lists.wpkg.org/mailman/listinfo/wpkg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20090728/26b42562/attachment.html> |