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

[Kai Pastor]

- WPKG Client can run wpkg at shutdown.

- Scheduled tasks even for the System account can be created remotely 
without the need for psexec. See the schtasks command. (But note that 
schtasks depends on system language and version.) This is how I trigger 
wpkg (client) deployment remotely.

- Both scheduled tasks and wpkg client (the service) can be triggered 
remotely (by schtasks or by sc).

Actually I use WPKG Client on the clients and a few CMD scripts on the 
management server.

LAPLAUD François schrieb am 07.01.2011 15:50:
> 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.
>