Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
My "dream" software upgrader/installer/remover for Windows:
a) installable silently when doing unattended install (preferably in windows_installer.bat file to hide username and password when doing unattended install):
windows_installer --silent --server 192.168.1.1 --user john --pass password
Currently I'm storing the values in the registry and changing the access rights so that only System can read them (Might need to add Administrator to that too).
b) runs on Windows in the background, connects to the server using SSL (to secure username and password) when booting, and fetches the instructions, sends software installed etc.
I've not considered the need to use SSL at this stage. (And I'm not sure that I've configured MySQL to use that correctly yet either - but I will, one day.)
c) server part as a dameon (on Linux, as most of use run Samba I think): - configurable via https web interface
Time to confess - I've never done anything using https. My inclination would be to 'get it working' using http and then hope that someone else would be inclined to help me convert to https. (Although as I write this I realise that there's someone thinking 'but it's sooo easy! You just do <foo> and there it is.')
- can configure what clients should have which software
This I like.
- report which software which client has installed (and what is to be installed)
I think I'm coming at it from the other (wrong?) way - the client finds out what it has and what it *should* have and then tries to make the lists the same. I like the idea of the server being able to do the same calculation and "predict" what the client should be doing, though.
- "install" button to install/uninstall/upgrade the missing software now
For users? Sounds attractive. I've been thinking about having a web interface which would allow users to select applications for which we have a site license or are freeware and allowing them to choose which of those packages are installed on their desktop. Or to remove packages they don't like. (I have one user who swears by virtual desktops. I have others who swear *at* virtual desktops...)
- configure to install software on Winodws boot
I'd been thinking of installing software on the next boot always, but I can see that this would cause problems when, for example, a user has to reboot in the middle of work because Windows Update has just installed lots of stuff and only then remembers that he asked for <foo> to be installed on his machine at the next boot. And <foo> takes ages to install...
- configurable to install software from a password protected file server / ftp / http etc.
Don't immediately see how easy it would be to implement installations from ftp / http servers. Password protected samba servers would probably cover a high-enough percentage of uses for the time being, I hope.
So far there is nothing like it I think, WPKG would be the closest to it (but very far from what I described, too) - so I decided to develop a web interface for it (should be available in a month or two).
Sounds good - my initial attempts with WPKG were disappointing. I tried to perform an AutoIt install, which persisted in hanging when run from WPKG but worked fine when running on the desktop. A quick mail to the wpkg list didn't produce any examples of 'known good' autoit scripts, alas, so I don't know whether WPKG and AutoIt are compatible. (I know AutoIt is the last resort for many of us and in my opinion should Be Avoided if possible, but it's not always possible and I'd hate to implement a solution which only worked for those installers which play by *our* rules.)
These XML entries are quite OK - it's relatively easy to make a web backend for it, which I think would attract far more people than when they had to rely only on editing text files.
I think that's a very sensible point. Maybe I should add the ability to store 'simple' {install/remove/upgrade/test} commands in a database, using batch files as a last resort. I think it's important to have batch files (or perl / JScript / VBScript scripts, perhaps) available because they allow us to perform conditional processing which would get rather difficult in an XML entry. Well, so I think, but I'm speaking from a position of ignorance... anyone care to enlighten me?
WPKG lacks a lot, too - checking for installed software against Windows Add/Remove Software is one example.
That's more or less where I've been populating my 'test.bat' scripts from. (-:
<Snip - I'd outlined how a service might work at bootup>
How do we determine what should be installed/removed etc.?
Make a query to the SQL server with the work stations MAC address. Now, in my case (and I might or might not be representative of others) I'd like that query to lookup which licences I (as sys admin) have allocated to that hardware address, and then tell me the directories containing the install/remove/test scripts. I can see that might not be relevant for other people, so perhaps this query should be stored somewhere it can be changed. Anyway, one generates a list of packages which the server thinks should be installed. The client has kept a list of all those packages which it has installed in the registry.
Any packages which are on both lists are checked for upgrades and the 'upgrade.bat' script inserted into todo.txt. Packages which the server says should be installed but which are not listed by the client have a two stage process for installation; the client runs the 'test.bat' file to see whether it's actually there but the client didn't know about it. If it is, the client makes the registry entries and copies the remove.bat script. If it's really not there, then the client adds the 'install.bat' script to todo.txt.
Those packages which the client knows it's got installed but don't appear on the list from the server have the batch files from c:\netinst\uninstallers\Package.bat added to todo.txt (which were copied from the server when the package was installed).
<snip - use a screensaver as 'watchdog' in case things hang>
It would mean a loop then if we misconfigure something :)
Yes and no. One of the things I like about unattended is the stack nature of todo.txt. If a command fails, the command has already been removed from the stack. If that failure causes a reboot (by, for example, sitting at a prompt asking for user input and causing the watchdog to think 'the script said this stage should take 4 minutes, and it's now taken 6: I'm going to reboot') that line isn't re-executed. When the machine reboots, installation continues from the next command on the stack. Now, I can see here that we might end up with this:
install package A: okay; install package B: hangs; <reboot by watchdog> install update to package B: hangs; <reboot by watchdog> install service pack to package B; hangs; <reboot by watchdog> (etc)
but in this case it's not a loop in the sense that the user is locked out until someone comes along to help. Sure, it's a pain waiting for all those timeouts but *eventually* todo.txt is empty and the machine is useable again.
One way of getting out of this state is to have the watchdog stop the installer service from starting automatically before it reboots the machine. This stops the service and prevents further updates of software on the machine. (I'm sure there are better ways, but one is enough to start with.)
I think it's better if software is installed in a background (like WPKG does) - if something fails, user doesn't see it and can work normally - it's crucial if you manage a bunch of servers and clients remotely and have no physical access to them.
I agree. Please - does anyone out there have an autoit script which works in the background? That's the only thing which has forced me to abandon WPKG....
Yours,
Frank
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ unattended-info mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/unattended-info
