[wpkg-users] Running wpkg.js as System Account

[LAPLAUD François]

It's not possible in my organization to have every computer running deployment script at startup : too many computers startup at almost the same time. Some packages will be quite big and, as said before, WAN (understand "slow" interco network) links must have a random waiting time because if there are only 4 or 10 computer booting during a 15 minutes delay on a 4Mbits and there are 10 MB or more package deployed to thoses machines, the best way would be for me to not deploy at boot, but later cause as you said, deploying software when users are working won't slow down their computers thanks to its perf.

I think a service would be usefull if it could add features like "agents" usually do ie :
- wake up / force package deployment remotely.
- periodic "ping" to check alive computers
- and best of all, be able to design a "master" computer per subnet storing the whole packages and sharing them with local neighboors to not overload the network.

Anyway, it's just my opinion ;)



-----Message d'origine-----
De : Natxo Asenjo [mailto:natxo.asenjo at gmail.com] 
Envoyé : vendredi 7 janvier 2011 15:30
À : LAPLAUD François
Cc : wpkg-users at lists.wpkg.org
Objet : Re: [wpkg-users] Running wpkg.js as System Account

2011/1/7 LAPLAUD François <laplaud at sdis72.fr>:
> Yes indeed,
> Here are my needs :
> - a working wpkg ( ;-) )

I would start with this. Just follow the wiki
http://wpkg.org/WPKG_QUICK_INSTALL guide.

> - possibility to run wpkg periodically to be able to deploy packages in background while users are working. For my part, I won't force shutdown, but when I need it, I will add an install cmd in my packages using msg.exe telling the user to Reboot when he can to complete an update. (to run it periodically I thought about scheduled tasks. If I need to use scheduled tasks, why would I run a service wich will in return run a script  whereas I can run that script directly ? in
both cases I will have to create a scheduled task...)

No, if you have a service you do not need to create a scheduled job.
That's the point of running a service, it runs automatically after
booting. You can create a job to run at boot time, but that is not a
service.

You can have both. While I can understand you do not want to have
both, it will be easier for you to have both. Bootstrap the client
installation so you know it's working, then install scheduled jobs
with it to run it periodically. This is redundancy, it can never hurt.
We run our wpkg and our cfengine frameworks like this.

Besides, the wpkgservice is not a typical one. It does not reread its
config continually. it just runs after boot and then sits there doing
nothing. It will not consume any significant resources.

> - when the scheduled tasked is about to run wpkg, I would like it to wait for some random time between 1 and 30 minutes for instance so that the network is not overloaded. (I suppose this part will need little modifications of the wpkg.js script itself but seems to be a quite easy one)

If you run it as a service you do not need to worry about this. Not
everybody turns their pc on at the same time. In the time we have been
running this, I have not seen significant problems even with large
packages (well, we do have fast networks, that helps too). We are not
deploying it to wan offices with slow links. If you have slow wan
links, then this could indeed be a problem with large software
packages.

What I like about wpkg is that it runs quite fast, so usually
everything is done while the user is getting some coffee after turning
their pc on. With our new workstations you really need to know
something is being installed because they are so fast that I usually
have to check the event log to see any activity, it's done before I
know it.

-- 
natxo