[wpkg-users] stop wpkg from removing packages

Rainer Meier r.meier at wpkg.org
Wed May 20 01:09:39 CEST 2009


Hi Simon,

simplesi wrote:
> Well the legitimate use is that I'd like to do it and I don't think anyone
> or any computer dies as a result of doing this :)

OK, I have to admit that the wording here was probably not perfectly chosen. Of
course nobody dies and nobody prevents you from doing it.
I intended to point out that I see no general requirement to support this way of
 (in my eyes mis-)using of WPKG. Mainly because I am sure it will lead to
problems and neither me nor the people supporting WPKG would like to be flooded
by problem-reports from people using this "feature" even without exactly knowing
the constraints.


> I only ever once had the need to remove a package (the original Giant
> Antispyware before MS bought the company and turned it into Defender)

Seems your environment is really "stable" and not touched for years. Still using
Win 98 and the same software since years. Well, good to know in which
environments WPKG is running...


> I just removed the package from packages.xml and installed a new package
> that did the removal.

Again, that's not really a clean way to do it but yes, it might work. However if
you use WPKG to do so then every WPKG query will show that "Antispyware" is
supposed to be installed in parallel to "Defender" which is not true because
"Antispyware" is not there any more.


> I'm sorry if I'm the only one that gets their xml messed up sometimes :(

You're for sure not the only one but WPKG is designed to handle such cases as
clean as possible doing a clean removal if you remove a package and a clean
re-install if you re-add it.


> As I said, I get 3 hours a week in each school - not a lot of time for
> package deployment testing in between changing printer cartridges/paper jams
> :)

I am also managing a school configuration using WPKG but I probably visit it
once a month for about 2 hours. Usually to pick up the install CD for a new
software (which I deploy remotely then by pushing the WPKG update to their
server via RAS) or to fix some non-networked stand-alone machines. Paper jams
can be fixed by instructed (teacher) personnel ;-)


> This wasn't a big request - I just thought wpkg should be able to do it :)

Valid request. However my personal opinion you read above. I see some
constraints and possible problems with such a change. Probably you will run into
such problems once too.


> Its hard to see the endless reboot happening, from my view if no package is
> ever removed, there is no harm in leaving an entry in wpkg.xml - wpkg will
> just say the package is missing and just not do anything - its hard to see
> that doing nothing can cause my machines to re-boot :)

If the packages are still listed within wpkg.xml (which is exactly what your
change will do) then WPKG will verify the package during synchronization. In
your case WPKG will try to remove every package which is within the local
wpkg.xml on each synchronization run (so the queue of tried removals will grow
on each change).
If you use the /noremove flag the removal process will be skipped, but WPKG will
retry on each run to run the remove commands (which are skipped each time due to
the /noremove flag).

Actually I had a look at the code (well, it's late now here) but as far as I can
see the /noremove flag would work for you in case you define appropriate checks
for your packages. This way WPKG tries to remove the software packages which are
not in your server-side package database but skips the execution of removal
commands.
As long as your checks yield true (package installed) it will stay within
wpkg.xml (this also happens if you do not specify any checks).
WPKG only removes the wpkg.xml entry if your checks defined return false (if
there is really something missing).
So you might try to use the /noremove flag with pakages which are either not
speifying any check or even better specify checks which yield true (which is
anyway required for successful installation).

I will try to do some tests as well but actually that should leave you with a
setup where WPKG only removes packages from wpkg.xml in case the software is
(manually) removed.


> I think for some reason, you've decided to attack a humble long time servant
> and admirer of wpkg which is an ideal tool to use in small schools without
> having to go down the domain controller/AD/GPO locked down client route.

It was not my intention to attack. Sorry if I offended you. I am basically using
WPKG in similar environment it looks. However there is one difference between
our setups. I use WPKG to track installation & uninstallation - so I prefer to
have a defined environment at every point in time while it seems you don't care
too much about the exact system state.

What offended me (personally) a bit was your statement that WPKG should handle a
state where a clear misconfiguration (accidentally removed package) should not
lead to WPKG action. This is somehow against the basic principle of such a tool
from my (just my personal) point of view. I still think such a tool should
exactly do what I tell it to. In case I remove a package it should remove it ;-)

But you might try my suggestion about /noremove flag again. Just make sure to
define appropriate checks.


> The machines aren't mine - there is no network manager - software is
> installed by myself and teachers - we have one logon (with no password).

Same for me. But my teachers are the only ones having the local admin password.


> My "users" are children up to age 11 and they think hacking is changing the
> wallpaper to a picture of a football team :)  (which I correct by having
> wpkg change it back again the next day)

Same for me here but kids today know how to access the control panel and click
on the nice Add/Remove Software icon and yes, they will try to click on these
nice buttons too.
Some of them also just follow some instructions they found on the internet (like
"you might increase your disk performance by using 'format c:'...").
OK, maybe your kids behave differently than the ones here in Switzerland but I
am not willing to take the risk anyway.


> I'm not running the computer section of the FBI :)

I guess they won't use WPKG - if I am wrong please tell me :D


> I hope, once your indignation that someone like me is allowed to  set up
> computers goes away :), that you might think that its not such a stupid idea
> :)

I already had countless discussions with so called "system administrators" which
did not even have a clue about user permissions and things like that. Probably
you're aware of most of the constraints but from your messages this was not
clear to me (and still isn't).
And yes, I still think using any sort of package deployment or policies in an
environment with undefined targets (where all users have full access) leads to a
very high risk of running into trouble. And as soon as people run into trouble
they will show up in the mailing list again and complain about the tools they
use. Would not be the first time I get complaints about WPKG not running on
certain clients but on these clients the user switched off all non-Microsoft
services (including WPKG client). Such support request mainly waste time of
voluntary support people here in the list.
And yes, it's annoying to trace down such non-bugs. That's why I intended to
stress on the fact that you should probably re-think about the security concept
you applied and if you keep the current concept then you should be aware of the
(possible) consequences.

So finally I hope you will continue to use WPKG - or let's say it will serve
your needs too.

br,
Rainer



More information about the wpkg-users mailing list