Hi Vasaris, On 27.02.2010 18:51, Vasaris wrote: > Does that means, that I have to change server-side WPKG files and folders > tree, and then find & add this patch to try it out?
Actually you would just have to replace wpkg.js with the patched one from Bugzilla. If I am not wrong it might be the one posted here: <http://bugzilla.wpkg.org/show_bug.cgi?id=118> Caution: I did not verify or ever use this version. > I very well understand this issue. If you go open-source and try to avoid M$ > as much as possible, using AD is an overkill. And it is better to have > reduced functionality, then a mess with non-working code. It's not only to avoid Microsoft. It's mainly about testing possibilities and also about language capabilities. WPKG uses JScript which is no longer actively supported by Microsoft and the language capabilities are quite limited. At some points we are entering some undocumented and even unstable API areas which might lead to problems. As soon as we would officially announce AD group support people will start using it and expect it to work. In worst case we will get requests to implement things which cannot be done using JScript. On the other side testers and developers would have to verify each enhancement/change for AD code parts as well. Not everybody might have licenses of the respective server software to build an AD. On the other side if there is no AD support this will just enforce admins to duplicate some information which is supposed to be quite static. So the drawbacks seem not to be a no-go criteria to me. However with an architectural change I would like to achieve certain decoupling between XML-based configuration and AD-based configuration so impacts should be smaller. >> So for the moment we stick to XML package/host/profile definition. > > This is not a big deal. It just means, that in my case I will have to > maintain two membership sets. > > Perhaps there is workaround by using some tool to dump security membership > content to the profile-host XML files. Therefore, such tool/script might run > periodically to upate WPKG XML files to reflect current AD security group > memberships. There are some script examples on wpkg.org already: <http://wpkg.org/WPKG_with_Active_Directory> Either this or some modification of it would allow you to generate hosts and profiles.xml from active directory. Running it frequently using the task scheduler should be a way to go as well. Even without affecting WPKG and having to introduce code to wpkg.js which might break or at least create unnecessary complexity. Another reason for me is that WPKG currently only uses SMB/CIFS shares and reads files from it. Remember that wpkg.js is running on the client within WSH. So accessing AD structures from the client is a new communication channel which introduces potential problems (like firewalling, timeout, privileges etc.). WPKG is run from the local system account which might (not must, but might, will have to verify) have impact on the privileges required to access AD structures. Running an export/synchronization script on the server which fetches data from AD and writes it to XML seems to be a much more clever way to go. Another negative side effect of integrating AD connectivity in wpkg.js is just the code overhead. Currently wpkg.js is already ~200kB in Size which has to be fetched by WSH and run within the interpreter. Adding AD/LDAP support might easily add another 40kB of code. Sorry for the longish explanation, I was just in the mood to summarize the topic again since it pops up from time to time. So in the future I can refer to this message where my main concerns are already written down. br, Rainer ------------------------------------------------------------------------- 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
