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

[bugzilla-daemon at bugzilla.wpkg.org]

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

--- Comment #2 from Keith Jones <k.e.jones at brighton.ac.uk>  ---
Hi,

(In reply to comment #1)
> 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.
> 

 You're right my description sucks as usual ;-)

 I was trying to suggest that, as it's so easily possible maybe it could be
formally adopted as a supported "feature" with pre-defined file locations etc
:-)

> 
> > 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.
> 

I totally agree with your thoughts here. Unfortunately, there's not much that
can be done except complain back to the software vendors, repackage the
installer or deal with it manually. In the interrim, I thought I'd look at the
idea of doing exactly as you detail below. It looked so easy so I thought I'd
make this suggestion :-)

> 
> >  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.
> 

 It's good to see someone's already exploring the idea. I did do a quick search
but I obviously didn't get the right keywords. I'll look harder. I'm probably
covering old well-discussed conversations.

> 
> > 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 know :-) ...but from my lazy point of view, a switch and a bit of extra code
could do all those changes for me in a consistent documented way ;-)

> 
> > 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.
> 

 You're not missing the point. We're just talking about the same thing from
different viewpoints :-)

 As you say, it can all be done with different config file settings and
different instances of WPKG. Having WPKG do it for me though... well, it'd be
another magical moment where WPKG saves the day :-)

 I did find some wrinkles to using WPKG as a per-user installer shortly after
writing that original message. I guess whoever is already using WPKG for per
user install has already mentioned them but for the record...

For Host matching;

 a) Group matching uses a hardcoded $ to retrieve groups the machine is a
member of so it'll never retrieve groups a user is a member of.
 b) Some matches could be skipped (IP matching etc)
 c) People would have to be careful about wildcard matches, particularly where
they've used "*" as a catch-all match. A separate equivalent to HOSTS.XML file
could be important. (handling this might not be trivial)

For general issues;
 b) *Some* extremely badly designed installers still write to
HKCU\Software\Microsoft\Windows\Current Version\Uninstall when they do a
per-user install. Perhaps the ScanKeys could do with adding HKCU to the search?

 Those "issues" (and I'm using the phrase very loosely, they're not issues with
WPKG's core use) would benefit from having a little more code and a
corresponding setting to switch them on and off.

 If you think of it that way, a /context:"user|machine" switch does seem to add
value to WPKG :-)

 I hope that makes more sense !


> 
> br,
> Rainer

All the best, and thank you for keeping WPKG just awesome to use :-)

Keith

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