[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 Stefan Pendl changed: What|Removed |Added CC||pendl2mega...@yahoo.de --- Comment #4 from Stefan Pendl --- (In reply to comment #1) > > cscript.exe \\path\to\wpkg.js /config:config-usermode.xml /host:%USERNAME% > Thats a really dirty hack, since WPKG already supports environment variable matching. Example: http://www.wpkg.org/hosts"; xmlns:wpkg="http://www.wpkg.org/wpkg"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:noNamespaceSchemaLocation="../xsd/hosts.xsd"> Depending on the value of an environment variable the profile to apply will be selected. So the following is already possible: -- Stefan -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 --- Comment #3 from Rainer Meier --- > 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 ;-) And especially the documentation is one of the items I would be afraid of. It would be hard to explain why WPKG uses username as hostname when the /context:user switch is used. But if the user on purpose adds /host:%USERNAME% then it's clear that he just want to enforce WPKG to use the username as host name string. I mean it's not hidden in some program code but obviously stated at the command line. In general I am very concerned about such a change introducing issues and pretty "obscure" concepts for a use-case where WPKG was not intended to be used. To state it clearly, WPKG from my point of view is a tool for system administrators to maintain system-wide settings. There are other mechanisms like policies, ActiveSetup, Logon-Scripts etc. which are designed to target enforcing user settings. Obviously WPKG can also be used in such environment already using special configuration. But honestly I don't feel like we should document and support this use case officially as it's clearly very limited use-case and requires extremely careful package definition and WPKG configuration to work properly. > 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 :-) Even if WPKG would implement such a context switch it would still require to independent instances. Unless we just duplicate the configuration parameters and allow then to be defined independently. For example the location of wpkg.xml would have to be configurable in config.xml as well (unless it's hardcoded to %AppData% in user context, but this is something I really wouldn't recommend). > 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) I guess this all refers to extended host attribute matching. In a) I guess you refer to group membership checks which should apply then to the local user rather than the machine. One could also use a simple cmd script to check for user group membership and use "execute" type checks rather than extended host matching. For b) I can only say that IP matching and also other host attribute matching is only performed if such checks/matches are used in packages. So we don't gain anything if we disable these checks globally. Not sure about c). The matching in hosts.xml and profiles.xml would be the same as for hosts if the username is used as hostname. Moreover if you use the /profile switch then this is ignored and WPKG selects a profile directly. > 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? I think I have disabled this mainly due to performance issues. Scanning the HKCU keys adds performance penalty. However in user-mode of course you might want to check for uninstall entries. But you can still do this using a very simple registry existence check. > 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. And this is the key point here I guess. The use of WPKG in userspace is not intentional even if it might work already very well. Officially supporting this use (or even encourage it) would require all features to be tested in another completely different environment. I doubt that the amount of installations using WPKG in userspace justify this additional complexity and test effort. Especially since WPKG even with the current features set is able to deal with all use-cases I can think about right now. Maybe you have a concrete use case which does not work in userspace with the current implementation. Up to now I just see a big source for confusion in special user-context mode and added test/development effort for the purpose of supporting an environment which is perhaps better maintained using different technology like Group Policies or ActiveSetup. The use of WPKG in userspace is very, very limited: - System administrators do not want to maintain software (core purpose of WPKG) in userspace - System admins would rather use Group Policies or ActiveSetup to enforce user settings (no WPKG needed here) M
[wpkg-users] [Bug 273] Per user install support
http://bugzilla.wpkg.org/show_bug.cgi?id=273 --- Comment #2 from Keith Jones --- 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: > > > > 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 >
Re: [wpkg-users] MSI + MST: MST somewhat ignored when silent install
G'day all Thanks for Paul and Geoff's answers - I wanted to answer when I had the opportunity to try another time. The installshield wasn't one with .iss - the logs clearly showed it was only doing a custom install but other customization like Icons and so forth were recognized by the MST install. I finally stumbled upon the variable INSTALLEVEL which had the value 100. When found this document over here: http://kb.flexerasoftware.com/selfservice/viewContent.do?externalID=Q103232 I tried Installlevel = 150 and it worked also silently - yay :-) Just need to wrap this up in a nice WPKG xml and make up the 3 other parts of this software. I hope I can give back the MST and XML into the wiki seems to be a software our german Bio and Chemistry teachers seem to like so (too) much ;-) Thank you guys! -- Mathieu - wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
