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

[bugzilla-daemon at bugzilla.wpkg.org]

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

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

 Thanks for responding with such depth. I do appreciate the attention you're
giving to this idea.

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

  Yes. I think documentation could be an issue. I would have thought that WPKG
appeals to people with some experience in the field though. At least, I would
hope they would have enough experience to separate the idea of running a script
at per-machine level (startup) as opposed to per-user level (login). (Not that
there is too much difference in reality). I think it could be explained well
though. It could still be listed as "Experimental" in the current RC. I can
have a stab at the documentation if you like.

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

 Hrmmm.. I probably don't see it as "obscure". At least one other person
doesn't anyway ;-)

  IMHO, it fleshes out WPKG to be an all-round deployment system. One one hand
it's a powerful, reliable tool for administering system-wide settings but it's
also a very well engineered and thought out "job" management system. I am very
conscious that it's not a task that it was originally intended for but, the
functionality is so close in nature that it feels like it's just a simple step
away.

  There are many ways to achieve the same effect (as you mention) but from
personal experience they're flawed, limited and rarely as easy to work with as
WPKG (Certainly not as integrated or centralised).

  I use GPO's to hand out policies, preferences, shortcuts and files but it
does get complex handling those settings in the precise way that WPKG does. It
usually ends up with some careful and complex layering of policies and some
rather interesting uses of permissions and filters to stop GPO's being applied
when my AD structure is more logical than my users are :-)

 As for login scripts, well, that's exactly where I see WPKG making an
important impact for myself (and many others I hope!). Our central IT support
team don't support roaming profiles. Every user login has things "prepared" by
a rather dauntingly long logon script. The script is full of checks for ABC
file being present, DEF user being logged in, GHI machine being the machine
they logged in on and then does something because of it. It's a huge amount of
wasted coding time when WPKG already has that built-in in simple definitions.
When I throw in "ExecuteOnce", reboot control etc, it just becomes a cool
repalcement for logon scripts.


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

 True. and I've got a test setup going out tomorrow based on your suggestions.
It's actually going to very successful I hope. I think there's a potential case
here, I'm hoping there'll be some comments from the list at least :-)

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

 Yes, totally. You'd still need to run the original copy via startup scripts,
WPKG Client or WPKG-GP and then run the second as a user logon script. The
beauty of it is that you could add the second instance directly as a single
line in a global GPO and let WPKG handle the structure you've set up.

 Choosing locations for files for the wpkg.xml file actually doesn't seem to
much of a problem in my head. I actually do think %APPDATA% is the ideal
location. I understand that you wouldn't recommend it but %APPDATA% is actually
the location where Windows expects data files to be for programs. Yes, you're
right, it's a good security move to block .EXE files but data files are another
thing. I guess I need to look a bit deeper at this but I think that fits with
MS's guidelines. I'm still looking at the product I mentioned as a problem. It
does make sense for a .accde file to be placed there; it's not really an
executable, it might need to roam with a profile but it still needs to be in a
writeable location. People can accidently delete stuff from "My Documents" so
it's actually not a bad location to hide the file to keep the "Application"
going. It still sucks ;-)

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

 Yes, that's exactly the idea I was mentioning.

 True but a little tweak and WPKG could do it for me. Maybe a different take on
this would help sell this better :-). If you have a hundred users of WPKG,
there's a hundred people writing their own scripts to handle this. That's bound
to lead to 100 different solutions. Essentially, some of those people will ask
you for advice so maybe it'd be more work for you answering them?

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

 I was only aiming for something simple, like, if the "user" switch was on then
just skip the tests. I must have read the coding wrong, I thought your could
match hosts via IP address. I've never investigated it so I probably I'm way
off target here!

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

Yeh. This one takes some explaining. If you implemented this idea then there's
bound to be some problems if the design doesn't find a way to automatically
work with a separate hosts.xml(maybe default to user.xml?).

 What I was trying to say was that if people use a catch-all host definition
there's a risk that it will automatically get applied to the machine during the
user logon and all the packages that need permissions will suddenly try to
install and havoc will occur.

 Stefan has responded with an alternative which needs thinking about. If you
don't mind, I'll respond to that comment with more detailed discussion on this
aspect.
> > 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.

No problem:-)

 In essence, I see them as redundant from a machine level perspective too
(there's bound to be a few wierd installers that add the same keys under the
LocalSystem account. Such is life!) but I think it's slightly more important to
have them for per-user installs. Besides, if all this extra processing is
switched on or off by a command line parameter, you can use that switch to
determine if they're added back in to the ScanKeys routines and the performance
side will also not impact WPKG's usual duties :-)

> >  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)
>   Moreover WPKG can be very well used to maintain ActiveSetup configuration on
> hosts
> If a system admin still wants to use WPKG to maintain user-space software, then
> this is already possible (ie not actively prevented) by WPKG. Although the
> system admin would anyway have to be extremely careful about package creation
> on userspace packages.
> > If you think of it that way, a /context:"user|machine" switch does seem to add
> > value to WPKG :-)
> Your explanations do make sense, but you have not been able to convince me yet
> that such a setup needs specific handling by WPKG. Also in the future I do not
> plan encouraging admins to maintain userspace settings/software using WPKG
> since this is a very fragile task and I believe it's usually leading to some
> mess, either with or without the /context switch.

 Thank you. I'm always conscious that I'm not the most concise person in the
world. I do tend to be a bit fluffy with ideas and I do miss a lot of subtle
issues and logic. Sorry! :-}

 This time though, I think maybe that WPKG itself sells the idea. You've made
it incredibly logical, reliable and smart. I feel it's really very capable of
approaching the idea without problems. It's a powerful system and letting that
power loose, as a tool for handling user-side changes, would be a wonderful
thing.

 Without a doubt, you've done a brilliant job, WPKG can really do the job :-)

 I'm not much of a salesman am I? :-)

 Seriously, it's a brilliant system.

Keith

PS: I deeply appreciate this is more work. I'll try and get some time together
to submit a patch/diff. I'm just not as good as you'd be...

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