[wpkg-users] stop wpkg from removing packages

[Rainer Meier]

Hi Simon,

simplesi wrote:
> I just run it as a logon script in c:\docs and settings\allusers\program
> files\startup and don't worry too much if the install isn't silent.

Man, I really think you should read a bit about user privileges and software
deployment. If you're able to run software installation from the startup folder
(which is run with user privileges) then this means that your users have full
administrator privileges.

If so, then you have much bigger problems than just some AutoIt scripts not
running. At any time any user could change the software configuration, screw up
some settings or change whatever they like. So you have absolutely no control on
the environment and there are far more problems to be expected than just an
installer popping up an "unexpected dialog box". Moreover these dialog boxes can
be handled using AutoIt, just check for a windows with a specific name to pop up
and if it does not pop up after a timeout, then it will never...

However I don't like AutoIt at all usually. All installers I had to use now have
silent options - or the app can be deployed silently using a set of scripts (cmd
script + 7-zip + reg-files).



> I go into each school for 3 hours/once a week and it is quite easy to make a
> "small" change and then find everything goes horribly wrong the next morning
> when the machines re-boot :(

As said above. I think in your setup this could happen any time. Especially
users could remove the packages manually - so you could run into exactly the
same problems as with WPKG if users remove some files/apps.


> Looking further at config.xml I saw the /noforcedremove flag and tried
> setting that as its explanation of its use seemed to be what I'd like to
> happen.
> 
> But it didn't :(
> 
> But I think it should do what I want - eg not remove the package from
> wpkg.xml if it is removed from the profile or package database.

The /noforcedremove flag has a different purpose. It disables removing of zombie
packages. WPKG will still try to uninstall the software if removed from the
package database. Just in case the uninstall fails WPKG will usually remove the
wpkg.xml entry in any case to prevent remove-loops (each run WPKG re-tries to
remove the package).


> I have made a small modification to a copy of wpkg.js and it now does the
> behaviour I'd like but it would be much better if was done "properly" :)

The easiest way might be to remove the contents of removeSettingsNode() or replace
return removeNode(getSettings(), packageNode);
by
return true;

And then make sure your packages do not contain any remove commands (or remove
the execution of remove commands from wpkg.js too).

This way wpkg.js will never remove any settings node. But hey, I really don't
see any legitimate use case for this. If the settings nodes stay within wpkg.xml
WPKG will have a different state then the system might have. For example a
package might be (manually) removed (remember you users have admin rights) but
WPKG will run the checks of all installed packages to verify them on each run.
So you will have no possibility at all to remove those package definitions from
the systems. So any package you really want to remove you need to go to each
machine and manually remove the software as well as manually edit wpkg.xml. This
is really totally against the principle of software deployment.


And everything just because you sometimes (by accident) mess up your server-side
package database? I think you should seriously think about your testing
procedures take more care about the package database.

If you continue to use your changed wpkg.js (of course you're free to do so) I
am pretty sure you will run into strange problems on these machines in the
future. In worst-case this might end in an endless reboot of your machines.

br,
Rainer