[wpkg-users] [Bug 273] Per user install support
bugzilla-daemon at bugzilla.wpkg.org
bugzilla-daemon at bugzilla.wpkg.org
Mon May 21 22:39:42 CEST 2012
http://bugzilla.wpkg.org/show_bug.cgi?id=273
--- Comment #14 from Keith Jones <k.e.jones at brighton.ac.uk> ---
Hi Rainer,
My apologies to everyone reading the blank message on Friday. My original
reply crossed-over with Stefan's and I hit the wrong button when I submitted
it. I haven't had much time spare to rectify that but I guess that having a
weekend to think things through was useful in putting things back in context
:-)
Sorry!
(In reply to comment #11)
> Hi Keith,
> I will have to go through all these comments in a bit more detail. But
> currently the summary to me really looks as follows:
> No matter if a context switch for user|machine would be implemented you would
> be strongly advised to set up an independent instance of WPKG with an
> independent package/profile/configuration structure due to a couple of reasons:
> - access permissions to the user-space WPKG shares and definitions are likely
> different from access-rights to the software repository
No problem. I'm realizing that what seemed trivial actually has a lot more
skilful thinking behind it now.
Now Stefan's comments make absolute sense. I was forgetting some package
definitions might have license key information etc. (I forgot that because
typically I stick the license files in the software repository itself, that way
I can secure a singular piece of software outside of how I use WPKG).
> - WPKG in user-mode should also allow configure where wpkg.xml is stored and
> how
> it's named, so an independent config.xml should be used
Yeh, I missed that subtlety :-) Of course... it'll just look for config.xml in
the root of the new instance. No need to specify a specific filename for
config.xml. Doh!
> - Also logging configuration would require some adaptation in config.xml
I got that one on my own after the fact :-)
> - Defining user-space and machine-space packages in one single WPKG database
> (packages.xml) would technically be possible but I would strongly recommend
> to separate it
At the moment I'm experimenting with not separating them fully. I've added a
junction point pointing to the original instance of the packages folder. I've
done the same for profiles. My hosts folder is separate. That's purely because
I didn't want to be going to two separate directories to update files whilst
figuring this out but I had some inner sense of what wisdom you wre passing on.
I'm really lazy :-)
> As already pointed out by Stefan you could set up a WPKG instance to perfectly
> work with username-based profile assignment using conditional host/profile
> definition. Matching by environment variable USERNAME perfectly works from
> within WPKG and would allow you to do the same as I have outlined it using the
> /host:%USERNAME% launch switch. So if you don't like command-line switches,
> then just filter "in code" which means using conditional expressions.
> As said above I would really strongly recommend to keep user-space packages
> defined in an independent instance of WPKG and not mix machine and user
> packages in packages.xml. If you're running an independent instance you will
> also have independent config.xml files (one for machine-instance another for
> user-instance on a different share). In each config.xml you can define the name
> and location of the local wpkg.xml differently.
I'm trying Stefan's suggestion in combination with the separate instance. I'm
definately learning a few tricks and learnt some lessons :-)
> You have also asked whether a missing "hostname" conditional attribute equals
> to hostname="*" somehow. Actually WPKG only filters for values which are
> existing. So if you omit the hostname attribute, then WPKG will not filter for
> it. Therefore you're right, if you omit hostname, then this means the condition
> does not depend on hostname at all. WPKG internally just matches all the
> attributes in the condition and if one of them does not match, then it entirely
> ignores the statement in which the condition appears. So if you add a condition
> to a host definition and one of the conditions do not match, then for WPKG it
> looks internally like this host definition is not in the file at all (removed
> from internal structures before processing).
> So for me still it feels like you can easily use the full power of WPKG in
> user-space even without any change. The only two items where I see improvement
> are:
> - Scanning of HKCU uninstall keys
> - Query group membership of executing user rather than machine
> The first one could be enabled/disabled by a config.xml switch. Or (more
> preferrable to me) not even introducing a switch and just scan this key in
> addition to machine uninstall keys. WPKG implements some new caching mechanisms
> for uninstall keys which might not have a big impact any more. Alternatively
> you can use simple registry checks already right now.
> The second one will have to be evaluated. I would like not to mix the current
> group matching (machine group matching) and a user matching. Maybe a simple
> additional conditional-check attribute like "usergroup" could match for user
> groups rather than machine groups. So one could even combine user and machine
> group membership filters.
Scanning the HKCU keys would be great. I think you were definately right to
remove them for performance reasons. Maybe it would be wrong of me to twist
your arm to put them back even with the caching mechanism in place? They might
not be much impact but if you're working in an environment where hot desking is
prevalent (and there's no roaming profile support) it could have a dramatic
impact on other WPKG user's environment as profiles get rebuilt on the fly. I
wouldn't ant to add that as a complication.
I tried the attribute filtering today. It's a really quite smart concept. I
like it! The only concern I have at the moment is how everything fits together.
I'm reading the code itself to see if it sits better in my head but at least I
now know...
- Why you're not encouraging the idea of switches (more documentation
complexity, more "modes" to support).
- Why you're discouraging changing the name matching process (it's heavily
hardcoded compared to the new more flexible conditional-check attribute
matching concept. I look forward to seeing that grow!).
- Why you're looking at adding attributes (singular,flyweight re-usable,
atomic comparisons have so much potential to add quick testable features).
I'm reading between the lines here but, are you contemplating (one day in the
far off future) replacing the name matching and merging it into the attribute
matching? It does seem like a very interesting direction to pursue :-)
A new "usergroup" attribute would be very useful but there's still some
conceptual issues I'm arguing out with myself here (let alone putting a case to
you for!).
Could "usergroup" match against a more fully qualified group name?ie
"domain\usergroup" or "usergroup at domain.tld". Could it also be supported by a
"user" attribute that supplies the same for a user account? What I'm thinking
is that both your and Stephan's solutions work brilliantly but they're limited
to using the value of %USERNAME%. That leaves a big grey area where people
might want to discriminate between local or domain users/groups. I could extend
your option by using /host:"%DOMAIN%\%USERNAME%" but you can't do that easily
with Stephan's offer as it involves working out how two environment variable
comparisons work (I'm not sure how WPKG deals with multiple attributes as
filters yet).
I think I should offer some code to deliver some ideas as a patch (It's only
fair for grabbing your time!). I might have some time (children permitting) to
do some coding Wednesday to illustrate the idea. I think I've got a much better
grip of the idea now. Wish me luck, my 2 year old's got a cold...as usual!
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.
More information about the wpkg-users
mailing list