[kepler-dev] [Bug 5065] In shared or administrative installations, the ability to store modules.txt and extra modules locally. This way, the module manager will work smoothly on Windows without having to run as an administrator.

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5065

David Welker <david.v.welker at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
       Hours Worked|                            |40
    Remaining Hours|0.0                         |40.0

--- Comment #4 from David Welker <david.v.welker at gmail.com> 2010-08-09 09:21:10 PDT ---
To update, this Thursday we had a meeting where, among other things, we
discussed how to proceed with this problem. We agreed that one reasonable
solution would be for the user to be prompted to enter an administrator
password when invoking certain functions of the module manager.

This weekend, I researched the feasibility of this solution on Windows. And
this is a non-trivial problem. The feature in Windows that we would need to use
is known as User Access Control (UAC). The process of prompting a user for a
log on for administrative privileges using that feature is called "elevation."
The issue with elevating privileges, is that this generally cannot be done
except at program launch. One can either use the "run as" verb when launching a
program, or specify that the program needs administrative privileges upon
launch.

There are a couple of solutions to move forward here.

(1) Make the module manager an entirely separate program. Selecting the module
manager menu item will launch the module manager, but instead of launching it
as a dialog in Kepler, it would launch in an entirely different JVM. Upon
launch, the module manager would ask for the administrative privileges
necessary to modify its install location in Program Files. The issue with this
solution is that ending the Kepler process to restart a new Kepler might be
very tricky; how would the module manager know what process to shut down if it
was running in a different process.

(2) Make the processes that download new modules or change modules.txt separate
programs that are invoked in the background. Getting the progress monitor to
work in this situation might be tricky, since what would be measured is the
progress of another program and not a process occurring within Kepler. Also, if
a particular blog entry I have read on this is correct, the separate program
may need to be wrapped in another language other than Java. I am doubtful that
this is actually correct. For details, check this blog post here:

http://mark.koli.ch/2009/12/uac-prompt-from-java-createprocess-error740-the-requested-operation-requires-elevation.html

I don't see why the separate program that is invoked cannot be written in Java,
but the person who wrote this detailed blog post decided to write theirs using
Visual C++ presumably based on this belief.

(3) Simply require Windows users to open "Run as Administrator" whenever they
want to use the module manager.

(4) Make the module manager a separate program that is not invokable from
within Kepler. That separate program would instead always be invoked separately
and would automatically prompt for elevated administrative privileges when
opened on Windows.

(5) Write modules and modules.txt to a user area. This could lead to
significant inefficiencies, as modules would have to be downloaded potentially
multiple times on the same computer for different users. Also, such
centralization would prevent people from having the same module downloaded and
modified differently in different contexts, since reference would now be made
to a centralized module. Perhaps a scheme could be made to get around this
problem...

Anyway, of these five solutions, I am tentatively leaning towards a variation
on solution (5). The reason is that this could be a more universal solution and
would not require us to delve into operating specific issues with issues such
as with Windows User Access Control. The default is that the build could look
for modules as peers to the build-area folder. But a scheme to make them look
elsewhere (somewhere in the user directory) for installs could be devised. In
this way, the experience for developers would remain unchanged (you could have
multiple instances of the same module associated with different builds that you
modify differently) but users with installed versions would not have to try to
write into Program Files or other protected areas on other operating systems.

Thoughts by others on this problem are welcome, but for now I am going to
proceed working out the details on how a solution paralleling (5) could be made
to work smoothly.

-- 
Configure bugmail: http://bugzilla.ecoinformatics.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.