[wpkg-users] [Bug 273] Per user install support

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=273

Rainer Meier <r.meier at wpkg.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.meier at wpkg.org

--- Comment #1 from Rainer Meier <r.meier at wpkg.org>  ---
I am not closing this issue yet as I might not get the full request correctly.
But basically I would say this is already implemented and working.


> For instance, I now have a piece of software that is basically an MSAccess
> .accde file installed into the users %APPDATA% folder and not the machine's
> one. Desktop shortcuts are added to the user's profile to point to that file
> which circumvents the need for a per-machine install.

This is an awful way of deploying software. Especially in professional
environments (what WPKG targets to support) per-user installation is really
really a bad thing. It opens security holes and issues on many levels. Some
examples:

- Users might run outdated/vulnerable software
- Users might infect their profile but for "admin" it looks all fine
- Different users run different versions of the same software, which
  is a nightmare re to support

I personally usually block execution of binaries in data folders like user
profile to prevent this. Although installers like the Skype installer and
Chrome are doing exactly this. Chrome offers a business version at least which
deploys as MSI machine-wide. And even the default chrome installer installs
globally when run as admin with elevation.


>  As far as I can see WPKG still doesn't formally support per-user installs.I
> think it's definately robust enough to handle that with trivial changes and
> some subtle thinking :-)


WPKG never prevents running as non-privileged user. So you can entirely run it
as non-privileged user. The only issue you have to keep in mind is to create
packages which run unprivileged as well (do not ask for elevation and do not
terminate unexpectedly).

Configured this way you can run WPKG in user context or during logon script
(user context too) or any other way.

I think somebody on the mailing list also reported he's using WPKG to deploy
user settings. Therefore creating packages which do nothing more than dealing
with user settings.


> I would like to suggest the implementation of a /context switch with values
> "machine" or "user". The /context:"machine" being assumed as the default value
> and keeping WPKG compatible with current setups. The /context:"user" being an
> option you'd add if you run WPKG.JS as a user logon script.

I don't think  such a switch is required. When run in user context then WPKG
just executes as normal. You just need to make sure that if you're running in
user context you're not executing any action which requires elevation.
Therefore you should not run the same packages. I would recommend running an
entirely independent installation of WPKG (from different folder with different
packages and profiles).
You can also just run the same WPKG instance and use the /config switch to
point it to another configuration file.


> In theory, when supplied with the "user" value WPKG would only need to change
> two things;

> a) redirect the WPKG.XML path to the user's %appdata% folder.
>  b) switch host matching to use the currently logged on user instead of the
>    host machine/IP/etc.

Redirection is not required. In user context you can run WPKG with a different
config.xml. Either by running a completely separated installation of WPKG
(different installation folder) or using the /config command-line switch.
Just make sure WPKG does not try to write wpkg.xml into the system32 folder by
setting the settings_file_path correctly in config.xml:

<param name='settings_file_path' value='%AppData%' />

The second point I did not get correctly. Why should WPKG match the host for
the user? If you mean to "fake" hostnames in order to match the right profile,
then you can simply use the /host command line switch. For example in your cmd
script which launches wpkg.js you can write the following:

cscript.exe \\path\to\wpkg.js /config:config-usermode.xml /host:%USERNAME%

This would allow you to use the username instead of host matching if you wish
to do so. Alternatively just use the /profile switch to select the profile
directly - you might create a profile per user (profile name = user name) and
use /profile:%USERNAME%.


> I appreciate that this trivialises many things but I can't actually see many
> coding hurdles. I can't actually see many operational issues either. In theory,
> it should all work already it just boils down to how people implement their
> WPKG setups :-)

If you do it as proposed, then there is no coding needed to run WPKG in user
context.
I am personally even running machines with multiple WPKG instances run on
system level - just because my sysadmins in the office use WPKG but they don't
deploy all software I like. So I just installed my own instance and configured
it to use another wpkg.xml (wpkg-mypackages.xml). So my packages are handled by
my own WPKG instance and company-wide packages I leave up to the sysadmin.

>  I have an awful feeling that I'm missing something... surely it can't be that
> easy? There might be some performance issues but WPKG really is self-healing > so it could actually survive very well.

Well, maybe I am missing the point why we need some implementation here.


br,
Rainer

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