auto installing applications on network

[rickict]

hi i was just woundering if it was possible to use perl to
install applications automaticlly over a network?

i manager over 130 win98/winxp pc's on a network. and everytime someone gets some new software, i have to go round and stand at every pc click the "setup" executable (which i would have placed on the server) and then click "next" "next"
"next" "next" and then "finish". i have better things to do!

is this something i can learn to do with perl? and what area's of perl will i need to concentrate on. (ie sockets?)
could it work with telnet or something?
any help would be grate, or if you know of a better way, or better technology, i'd be pleased to hear .
thanks .......rick

 

[TrojanWarBlade]

I'm not sure this is possible.
How can perl click "next" buttons for you?


Trojan.

 

[rickict]

im sure ive seen the idea of scripts that predefine the installation's choices as to what packaged to install and where.
are there not ways to install OS's like windows with a predefined script so every pc just needs to have the setup.exe ran and left to install.
surely if that is possible the next challange is just to get the script to run from a remote machine.???
i have seen software that is for this kind of work, but as you can expect it cost a packet. and anyway i would like to make my own solution......cheers ....rick

 

[fishiface]

Many "setup.exe" installers take a /q switch which allows for unattended installations. Big sites must do it this way so anyone with pretensions to writing serious software will support such installations.

I've written a few such systems over the years with varying degrees of success. All have relied on a shared network filesystem and a start-up script. They have all evolved considerably and one lesson I learned early on was to get control away from the client as soon as you can. For example: if your OS or network environment doesn't provide a network start-up script and you need to put one on each client, then all it should do is make sure that it can access another script on a shared server and then run that. This gives you the most flexibility for growing the system over time.

I'll outline one technique that proved reliable and scaled up happily to around 100 client machines. It involved a couple of scripts on a unix host with a samba-shared directory. This directory contained, amongst other stuff, a "mods" directory with a subdirectory for each installation or upgrade candidate. The names of these subdirectories were chosen so that they would sort chronologically. Each time I needed to roll out an upgrade, I would develop a script to do the work and then create a new directory for it. I then had a utility which created a link to the script for each client, named after the client.

A single script on the client verified that it could contact the server and then ran the "master script" from the server with the client name as an argument. The master script went through all the subdirectories of the mods directory (in the correct order) looking for scripts named after the client. Any it found, it would copy locally, delete the original and then run the copy.

This provided a means for ensuring that each client ran each upgrade once and once only, in the correct order. It also made it quite easy to see, from the server, how each upgrade was doing.

I've since moved to a database-driven approach but would not suggest that anyone start with that unless they were very confident.

I hope this helps,

f

["]As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.["]
--Maur

 

[rickict]

thanks fishiface that gives me some ideas to start working with.

rick

 

[rickict]

TrojanWarBlade
i have just discovered that you can get perl to press buttons by using the win32::guitest module .there is probably others
as well. goto:

http://www.piotrkaluski.com/files/automation/gui/gui_test_tut/

to find a nice tutorial on it .

 

[fishiface]

Thanks, rickict. Great module with loads of possibilities. I've also learned some useful windows stuff from the tutorial.

f

["]As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.["]
--Maur

 

[TrojanWarBlade]

Well done rickict.


Trojan.