[EMAIL PROTECTED] schrieb:
(...)
unless we use "/force".
If we use "/force" no package will be removed, packages will be marked as
"installed" of kept out.
I meant if wpkg.xml is missing for example - it will then be "recreated".
But you're right, it's something else.
This patch does modify the remove-routines. If you remove the
"revision"-Attribute from a package inside the Server-packages.xml,
wpkg marks the package as "to be removed" and does handle it as if
the package-entry would have been removed completely.
So it will use the "remove cmd" on all workstations, right?
right. This procedure is only used (and useful) if you want to remove a
specific package from all computers.
OK.
As difference, wpkg tries to use the server-side removal-cmd"s first
and does fall back, if thre aren"t any.
DRAWBACK: The "revision"-Attribute becomes a REQUIRED ATTRIBUTE
You say that "revision" is required now, but just a while ago you tried
to encourage us to remove it from packages.xml? :)
I don"t understand it.
You will _not_ be able to _INSTALL_ or _UPGRADE_ a package which does not
have the Attribute "revision".
A package without "Revision"-Attribute is considered as "deleted or to
delete".
So a normal installed package does have a "revision".
OK.
My reasons why to change this:
1) possibility to modify the local file "wpkg.xml" is higher than to
modify a serverfile "packages.xml" (this IS a lesser security risk)
hmm? what do you mean?
The file "wpkg.xml" is stored local.
If a package is to be removed, the line
"<remove cmd='(uninstallcommand)' />"
is taken from this local file.
the /uninstallcommand/ is executed with the privileges of
SYSTEM or Administrator.
I see a potential risk:
By modifying the local file "wpkg.xml" any user can start programs with the
privileges of SYSTEM or Administrator.
But if someone managed to alter wpkg.xml, than that person probably can
execute tasks as SYSTEM or Administrator already?
My patch simply minimizes this potential by trying to get the
/uninstallcommand/ from the server first.
OK.
2) whenever you installed a program and made an error for the
installscript, you know the problem by yourself.
hmm? then it wouldn"t install if there was an error?
I'm already using an "advanced" version of wpkg (with different checks for
"install", "upgrade" and "remove".
I don't know others, but I do not have the time to cross-check every
computerconfiguration from our company before deploying a package.
Sometimes errors do occour. (Windows ACL can be a really good thing /if used
the propper way/)
Furthermore:
I did some tests with checkConditions and implemented the condition
"lesser". Later I renamed this condition to "lessthan" and my /remove/-cmd
did not work any more. So I invented this solution.
OK.
[snipped tryal of explanation]
So it is only a mean of mass removing a package, or what?
Sorry, I didn"t really catch the purpose of that :)
I hope the former lines made my point a bit more clear.
The patch does not modify the usual, original way of file-removal.
/If/ used, the patch minimizes a /possibility of fraudulence/ and can make
life easier for a sysadmin.
(...)
So maybe we should always use the "remove cmd" from the server?
For now I will add it "your style" :)
--
Tomek
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
wpkg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wpkg-users
